Created attachment 136410 [details] Crash log SUMMARY I opened a bug report a few months ago about this, and the fix didn't really fix the issue. It's still possible to access years before 0. STEPS TO REPRODUCE 1. Turn on "Astronomical Events" or "Holidays" from the calendar applet settings. 2. From the decade view, scroll to year 0 - 9. 3. Click on the year -1. 4. From the week/day view, scroll into the past. OBSERVED RESULT Plasma crashes. EXPECTED RESULT Not being able to access years before 0. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux 5.11.1, KDE Plasma 5.21.1 (available in About System) KDE Plasma Version: 5.21.1 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2
Backtrace with more debug symbols: Application: Plasma (plasmashell), signal: Floating point exception Content of s_kcrashErrorMessage: [Current thread is 1 (LWP 30819)] [KCrash Handler] #5 0x00007fda35c8b438 in KHolidays::HolidayParserDriverPlan::easter(int) (this=this@entry=0x7fffe99af728, year=-4) at /home/alois/kde/src/frameworks/kholidays/src/parsers/plan2/holidayparserdriverplan.cpp:235 #6 0x00007fda35c8ce0f in KHolidays::HolidayParserDriverPlan::parse() (this=0x7fffe99af728) at /home/alois/kde/src/frameworks/kholidays/src/parsers/plan2/holidayparserdriverplan.cpp:95 #7 0x00007fda35c81d7e in KHolidays::HolidayParserDriver::parseHolidays(QDate const&, QDate const&) (this=0x21bcb40, startDate=..., endDate=...) at /home/alois/kde/src/frameworks/kholidays/src/parsers/holidayparserdriver.cpp:55 #8 0x00007fda35c7bed9 in KHolidays::HolidayRegion::holidays(QDate const&, QDate const&) const (this=0x21e47b0, startDate=..., endDate=...) at /home/alois/kde/src/frameworks/kholidays/src/holidayregion.cpp:1078 #9 0x00007fda35c6c82b in () at /usr/lib64/qt5/plugins/plasmacalendarplugins/holidaysevents.so #10 0x00007fda35ddaf2f in DaysModel::update() (this=0x270c5c0) at /home/alois/kde/src/frameworks/plasma-framework/src/declarativeimports/calendar/daysmodel.cpp:90 #11 DaysModel::update() (this=0x270c5c0) at /home/alois/kde/src/frameworks/plasma-framework/src/declarativeimports/calendar/daysmodel.cpp:77 #12 0x00007fda35dd96b4 in Calendar::updateData() (this=this@entry=0x2712200) at /home/alois/kde/src/frameworks/plasma-framework/src/declarativeimports/calendar/calendar.cpp:296 #13 0x00007fda35dd9918 in Calendar::updateData() (this=0x2712200) at /home/alois/kde/src/frameworks/plasma-framework/src/declarativeimports/calendar/calendar.cpp:55 #14 Calendar::setDisplayedDate(QDate const&) (this=this@entry=0x2712200, dateTime=...) at /home/alois/kde/src/frameworks/plasma-framework/src/declarativeimports/calendar/calendar.cpp:47 #15 0x00007fda35dd9b2e in Calendar::setDisplayedDate(QDate const&) (dateTime=..., this=0x2712200) at /usr/include/qt5/QtCore/qdatetime.h:150 #16 Calendar::previousMonth() (this=0x2712200) at /home/alois/kde/src/frameworks/plasma-framework/src/declarativeimports/calendar/calendar.cpp:343 #17 0x00007fda35dd66af in Calendar::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=_o@entry=0x2712200, _c=_c@entry=QMetaObject::InvokeMetaMethod, _id=_id@entry=12, _a=_a@entry=0x7fffe99afde0) at /home/alois/kde/build/frameworks/plasma-framework/src/declarativeimports/calendar/calendarplugin_autogen/EWIEGA46WW/moc_calendar.cpp:231 #18 0x00007fda35dd7053 in Calendar::qt_metacall(QMetaObject::Call, int, void**) (this=0x2712200, _c=QMetaObject::InvokeMetaMethod, _id=12, _a=0x7fffe99afde0) at /home/alois/kde/build/frameworks/plasma-framework/src/declarativeimports/calendar/calendarplugin_autogen/EWIEGA46WW/moc_calendar.cpp:392 #19 0x00007fda83b9fd9d in () at /usr/lib64/libQt5Qml.so.5 #20 0x00007fda83a88a4e in () at /usr/lib64/libQt5Qml.so.5 #21 0x00007fda83a8afda in QV4::QObjectMethod::callInternal(QV4::Value const*, QV4::Value const*, int) const () at /usr/lib64/libQt5Qml.so.5 #22 0x00007fda83ab7cba in QV4::Runtime::CallPropertyLookup::call(QV4::ExecutionEngine*, QV4::Value const&, unsigned int, QV4::Value*, int) () at /usr/lib64/libQt5Qml.so.5 #23 0x00007fda595eba52 in () #24 0x0000000000000000 in () [Inferior 1 (process 30819) detached] The issue is caused by the easter calculation blowing up for negative years because division and modulo in C do not correspond to the mathematical definition of the operations for negative operands. I think the best fix will be to not calculate easter at all for negative years because it does not make any sense for obvious reasons.
(In reply to Alois Wohlschlager from comment #1) > Backtrace with more debug symbols: > > Application: Plasma (plasmashell), signal: Floating point exception > Content of s_kcrashErrorMessage: [Current thread is 1 (LWP 30819)] > [KCrash Handler] > #5 0x00007fda35c8b438 in KHolidays::HolidayParserDriverPlan::easter(int) > (this=this@entry=0x7fffe99af728, year=-4) at > /home/alois/kde/src/frameworks/kholidays/src/parsers/plan2/ > holidayparserdriverplan.cpp:235 > #6 0x00007fda35c8ce0f in KHolidays::HolidayParserDriverPlan::parse() > (this=0x7fffe99af728) at > /home/alois/kde/src/frameworks/kholidays/src/parsers/plan2/ > holidayparserdriverplan.cpp:95 > #7 0x00007fda35c81d7e in > KHolidays::HolidayParserDriver::parseHolidays(QDate const&, QDate const&) > (this=0x21bcb40, startDate=..., endDate=...) at > /home/alois/kde/src/frameworks/kholidays/src/parsers/holidayparserdriver.cpp: > 55 > #8 0x00007fda35c7bed9 in KHolidays::HolidayRegion::holidays(QDate const&, > QDate const&) const (this=0x21e47b0, startDate=..., endDate=...) at > /home/alois/kde/src/frameworks/kholidays/src/holidayregion.cpp:1078 > #9 0x00007fda35c6c82b in () at > /usr/lib64/qt5/plugins/plasmacalendarplugins/holidaysevents.so > #10 0x00007fda35ddaf2f in DaysModel::update() (this=0x270c5c0) at > /home/alois/kde/src/frameworks/plasma-framework/src/declarativeimports/ > calendar/daysmodel.cpp:90 > #11 DaysModel::update() (this=0x270c5c0) at > /home/alois/kde/src/frameworks/plasma-framework/src/declarativeimports/ > calendar/daysmodel.cpp:77 > #12 0x00007fda35dd96b4 in Calendar::updateData() (this=this@entry=0x2712200) > at > /home/alois/kde/src/frameworks/plasma-framework/src/declarativeimports/ > calendar/calendar.cpp:296 > #13 0x00007fda35dd9918 in Calendar::updateData() (this=0x2712200) at > /home/alois/kde/src/frameworks/plasma-framework/src/declarativeimports/ > calendar/calendar.cpp:55 > #14 Calendar::setDisplayedDate(QDate const&) (this=this@entry=0x2712200, > dateTime=...) at > /home/alois/kde/src/frameworks/plasma-framework/src/declarativeimports/ > calendar/calendar.cpp:47 > #15 0x00007fda35dd9b2e in Calendar::setDisplayedDate(QDate const&) > (dateTime=..., this=0x2712200) at /usr/include/qt5/QtCore/qdatetime.h:150 > #16 Calendar::previousMonth() (this=0x2712200) at > /home/alois/kde/src/frameworks/plasma-framework/src/declarativeimports/ > calendar/calendar.cpp:343 > #17 0x00007fda35dd66af in Calendar::qt_static_metacall(QObject*, > QMetaObject::Call, int, void**) (_o=_o@entry=0x2712200, > _c=_c@entry=QMetaObject::InvokeMetaMethod, _id=_id@entry=12, > _a=_a@entry=0x7fffe99afde0) at > /home/alois/kde/build/frameworks/plasma-framework/src/declarativeimports/ > calendar/calendarplugin_autogen/EWIEGA46WW/moc_calendar.cpp:231 > #18 0x00007fda35dd7053 in Calendar::qt_metacall(QMetaObject::Call, int, > void**) (this=0x2712200, _c=QMetaObject::InvokeMetaMethod, _id=12, > _a=0x7fffe99afde0) at > /home/alois/kde/build/frameworks/plasma-framework/src/declarativeimports/ > calendar/calendarplugin_autogen/EWIEGA46WW/moc_calendar.cpp:392 > #19 0x00007fda83b9fd9d in () at /usr/lib64/libQt5Qml.so.5 > #20 0x00007fda83a88a4e in () at /usr/lib64/libQt5Qml.so.5 > #21 0x00007fda83a8afda in QV4::QObjectMethod::callInternal(QV4::Value > const*, QV4::Value const*, int) const () at /usr/lib64/libQt5Qml.so.5 > #22 0x00007fda83ab7cba in > QV4::Runtime::CallPropertyLookup::call(QV4::ExecutionEngine*, QV4::Value > const&, unsigned int, QV4::Value*, int) () at /usr/lib64/libQt5Qml.so.5 > #23 0x00007fda595eba52 in () > #24 0x0000000000000000 in () > [Inferior 1 (process 30819) detached] > > The issue is caused by the easter calculation blowing up for negative years > because division and modulo in C do not correspond to the mathematical > definition of the operations for negative operands. I think the best fix > will be to not calculate easter at all for negative years because it does > not make any sense for obvious reasons. Interesting, by the way, is there a reason to keep negative years in? I don't think anyone would mind, if this was changed.
(In reply to Vojtěch Bartoň from comment #2) > Interesting, by the way, is there a reason to keep negative years in? I > don't think anyone would mind, if this was changed. The reason is that this is a bug in frameworks. Even when Plasma does not allow accessing negative years any more, nothing stops other (possibly external) users of frameworks from passing in negative years, and the library should show reasonable behavior in such a case.
(In reply to Alois Wohlschlager from comment #3) > (In reply to Vojtěch Bartoň from comment #2) > > Interesting, by the way, is there a reason to keep negative years in? I > > don't think anyone would mind, if this was changed. > > The reason is that this is a bug in frameworks. Even when Plasma does not > allow accessing negative years any more, nothing stops other (possibly > external) users of frameworks from passing in negative years, and the > library should show reasonable behavior in such a case. I see, thanks!
Git commit e4f65e74a84d90b6c1b24d8dd08dd3df5cc0ab86 by Allen Winter. Committed on 13/03/2021 at 13:06. Pushed by winterz into branch 'master'. handle negative years in easter and pascha calculations. in easter() and pascha(), return an invalid QDate when a negative year is specified. M +7 -0 src/parsers/plan2/holidayparserdriverplan.cpp https://invent.kde.org/frameworks/kholidays/commit/e4f65e74a84d90b6c1b24d8dd08dd3df5cc0ab86