Would disallowing access to years before 1583 be an acceptable solution here? The calendar is pretty much bogus before that anyway because it does not take into account the Gregorian calendar reform.

(In reply to Alois Wohlschlager from comment #1)
> Would disallowing access to years before 1583 be an acceptable solution
> here? The calendar is pretty much bogus before that anyway because it does
> not take into account the Gregorian calendar reform.

I've made three bug reports, and YES, your solution would fix all of them!

>Would disallowing access to years before 1583 be an acceptable solution here? 

It's important to understand why it breaks first.

It might be something that affects all years, and just happens to be a way to convenient way to trigger it. 

>Plasmashell freezes and has to be killed.

Please can I have a backtrace when frozen.

From a terminal:

sudo gdb --pid `pidof plasmashell`
then when it loads type "bt"

and paste the output

Created attachment 136451 [details]
Backtrace

(In reply to David Edmundson from comment #3)
> >Would disallowing access to years before 1583 be an acceptable solution here? 
> 
> It's important to understand why it breaks first.
> 
> It might be something that affects all years, and just happens to be a way
> to convenient way to trigger it. 
> 
> >Plasmashell freezes and has to be killed.
> 
> Please can I have a backtrace when frozen.
> 
> From a terminal:
> 
> sudo gdb --pid `pidof plasmashell`
> then when it loads type "bt"
> 
> and paste the output

GDB showed me an error (Error while reading shared library symbols for /usr/lib/libpthread.so.0:
Cannot find user-level thread for LWP 3753: generic error), but I hope I did it correctly. The backtrace is in the attachments.

Ok, so what happens is the following:

* The applet doesn't know that year 0 is not a thing, so it happily passes year 0 around. The "10" is actually a leftover from the decade previously visited, when you run plasmashell from the terminal, you will see the message ".../DayDelegate.qml:108:9: Unable to assign [undefined] to QString".
* Due to this, in .../plasma-framework/src/declarativeimports/calendar/daysmodel.cpp:90, two null (invalid) dates will be passed to eventsPlugin->loadEventsForDateRange.
* This function will enter an infinite loop because the loop variable "date" will be the null date, and hence always compare less-or-equal to the null date that was specified as the end of the range.

So this problem is confined to year 0, and possible fixes are either correctly treating it as year -1 or outright disallowing access to years that early.

(As an unrelated note, moon phases of dates not in the range of years 1933 to 2047 should be taken with a grain of salt due to overflow issues in the vendored Berkeley code. I will fix this soon.)

(In reply to Alois Wohlschlager from comment #6)
> Ok, so what happens is the following:
> 
> * The applet doesn't know that year 0 is not a thing, so it happily passes
> year 0 around. The "10" is actually a leftover from the decade previously
> visited, when you run plasmashell from the terminal, you will see the
> message ".../DayDelegate.qml:108:9: Unable to assign [undefined] to QString".
> * Due to this, in
> .../plasma-framework/src/declarativeimports/calendar/daysmodel.cpp:90, two
> null (invalid) dates will be passed to eventsPlugin->loadEventsForDateRange.
> * This function will enter an infinite loop because the loop variable "date"
> will be the null date, and hence always compare less-or-equal to the null
> date that was specified as the end of the range.
> 
> So this problem is confined to year 0, and possible fixes are either
> correctly treating it as year -1 or outright disallowing access to years
> that early.
> 
> (As an unrelated note, moon phases of dates not in the range of years 1933
> to 2047 should be taken with a grain of salt due to overflow issues in the
> vendored Berkeley code. I will fix this soon.)

Very interesting! If you're planning on fixing the issue, don't treat year 0 as -1. Negative years crash plasmashell, if you have Astronomical events or Holidays turned on.

>* This function will enter an infinite loop because the loop variable "date" will be the null date, and hence always compare less-or-equal to the null date that was specified as the end of the range.

Ok, lets fix this infinite loop as there are other ways that can occur.

Then I would have no objection to your 1583 idea.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/60

Git commit 1215a403cd6827a5f8ff4db5b276a49fe4245939 by Nate Graham, on behalf of Alois Wohlschlager.
Committed on 29/04/2021 at 23:36.
Pushed by ngraham into branch 'master'.

Remove potential for infinite loops in AstronomicalEventsPlugin

AstronomicalEventsPlugin::loadEventsForDateRange would potentially go
into an infinite loop in case one of the arguments is an invalid date or
the end date is the last valid date. Add extra checks covering these
cases.

M  +6    -1    plasmacalendarplugins/astronomical/astronomicaleventsplugin.cpp

https://invent.kde.org/plasma/kdeplasma-addons/commit/1215a403cd6827a5f8ff4db5b276a49fe4245939