Since the update to Gear 24.12.2 kalarm crashes on login. When I start kalarm manually with `kalarmautostart kalarm --tray`, i.e. the Exec command from ~/.config/autostart/kalarm.autostart.desktop, then it doesn't crash. Maybe this is related to my usage of kwallet (with OpenPGP) which I first need to unlock after login. STEPS TO REPRODUCE 1. Have kalarm configured for autostart. 2. Log in OBSERVED RESULT kalarm crashes EXPECTED RESULT kalarm doesn't crash SOFTWARE/OS VERSIONS KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 ADDITIONAL INFORMATION Application: kalarm (kalarm), signal: Segmentation fault [New LWP 3964] [New LWP 4061] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/bin/kalarm -session 10c9cd6e65000173925866800000030170017_1739306175_87705'. Program terminated with signal SIGSEGV, Segmentation fault. #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=11, no_tid=no_tid@entry=0) at pthread_kill.c:44 44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0; [Current thread is 1 (Thread 0x7f83e0b1ab00 (LWP 3964))] python sentry-sdk not installed :( Cannot QML trace cores :( [Current thread is 1 (Thread 0x7f83e0b1ab00 (LWP 3964))] Thread 2 (Thread 0x7f83dfd836c0 (LWP 4061)): #0 0x00007f83e530eacf in __GI___poll (fds=0x7f83dfd82968, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007f83e541e8a2 in ??? () at /lib64/libxcb.so.1 #2 0x00007f83e54203bc in xcb_wait_for_event () at /lib64/libxcb.so.1 #3 0x00007f83e0977378 in ??? () at /usr/lib64/qt6/plugins/platforms/../../../libQt6XcbQpa.so.6 #4 0x00007f83e5d1f597 in operator() (__closure=<optimized out>) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/thread/qthread_unix.cpp:375 #5 (anonymous namespace)::terminate_on_exception<QThreadPrivate::start(void*)::<lambda()> > (t=<optimized out>) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/thread/qthread_unix.cpp:311 #6 QThreadPrivate::start (arg=0x556f6eca22a0) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/thread/qthread_unix.cpp:339 #7 0x00007f83e5298292 in start_thread (arg=<optimized out>) at pthread_create.c:447 #8 0x00007f83e531d4fc in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 Thread 1 (Thread 0x7f83e0b1ab00 (LWP 3964)): [KCrash Handler] #5 std::__atomic_base<QMutexPrivate*>::load (this=0x0, __m=std::memory_order_relaxed) at /usr/include/c++/14/bits/atomic_base.h:831 #6 std::atomic<QMutexPrivate*>::load (this=0x0, __m=std::memory_order_relaxed) at /usr/include/c++/14/atomic:582 #7 QAtomicOps<QMutexPrivate*>::loadRelaxed<QMutexPrivate*> (_q_value=<error reading variable: Cannot access memory at address 0x0>) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/thread/qatomic_cxx11.h:202 #8 QBasicAtomicPointer<QMutexPrivate>::loadRelaxed (this=0x0) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/thread/qbasicatomic.h:170 #9 QBasicMutex::fastTryLock (this=0x0) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/thread/qmutex.h:77 #10 QBasicMutex::lock (this=0x0) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/thread/qmutex.h:40 #11 std::scoped_lock<QMutex>::scoped_lock (this=<synthetic pointer>, __m=<optimized out>) at /usr/include/c++/14/mutex:787 #12 (anonymous namespace)::qt_scoped_lock<QMutex> (mutex=<optimized out>) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/thread/qlocking_p.h:60 #13 QLoggingRegistry::installFilter (this=<optimized out>, filter=0x0) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/io/qloggingregistry.cpp:412 #14 QLoggingCategory::installFilter (filter=0x0) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/io/qloggingcategory.cpp:368 #15 0x00007f83b1dae0a2 in (anonymous namespace)::RemoteLogger::~RemoteLogger (this=0x556f6f06a010, this=<optimized out>) at /usr/src/debug/akonadi-24.12.2/src/shared/akremotelog.cpp:58 #16 (anonymous namespace)::RemoteLogger::~RemoteLogger (this=0x556f6f06a010, this=<optimized out>) at /usr/src/debug/akonadi-24.12.2/src/shared/akremotelog.cpp:62 #17 0x00007f83e5bf4e9e in QObject::event (this=0x556f6f06a010, e=0x556f6f06bbf0) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/kernel/qobject.cpp:1403 #18 0x00007f83e6fdee35 in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x556f6f06a010, e=0x556f6f06bbf0) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/widgets/kernel/qapplication.cpp:3296 #19 0x00007f83e5bada30 in QCoreApplication::notifyInternal2 (receiver=0x556f6f06a010, event=0x556f6f06bbf0) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/kernel/qcoreapplication.cpp:1172 #20 0x00007f83e5bb3a20 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=52, data=0x556f6ec6bf70) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/kernel/qcoreapplication.cpp:1946 #21 0x00007f83e5e6beb4 in operator() (__closure=<optimized out>) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/thread/qthread_unix.cpp:403 #22 (anonymous namespace)::terminate_on_exception<QThreadPrivate::finish()::{lambda()#1}>(QThreadPrivate::finish()::{lambda()#1}&&) [clone .isra.0] (t=<optimized out>) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/thread/qthread_unix.cpp:311 #23 0x00007f83e5d1f0b5 in set_thread_data(QThreadData*)::Cleanup::~Cleanup() () at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/thread/qthread_unix.cpp:386 #24 0x00007f83e52438e1 in __cxa_finalize (d=0x7f83e6043000) at cxa_finalize.c:97 #25 0x00007f83e5b2e9e7 in __do_global_dtors_aux () at /lib64/libQt6Core.so.6 #26 0x00007f83e78b7530 in ??? () #27 0x00007f83e87f4102 in _dl_call_fini (closure_map=0x7fff855b00c0, closure_map@entry=0x7f83e78b7530) at dl-call_fini.c:43 #28 0x00007f83e87f74ce in _dl_fini () at dl-fini.c:114 #29 0x00007f83e5243eb1 in __run_exit_handlers (status=0, listp=0x7f83e53f5680 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108 #30 0x00007f83e5243f80 in __GI_exit (status=<optimized out>) at exit.c:138 #31 0x0000556f6125970b in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/kalarm-24.12.2/src/main.cpp:86
It's not caused by autostart but by session restore. I can reproduce the crash when I try to run `/usr/bin/kalarm -session 10c9cd6e65000173925866800000030170017_1739306175_87705` as logged by the stack trace.
This crash has also been described in https://bugs.kde.org/show_bug.cgi?id=497742#c10. (Note that Bug 497742 is about an unrelated issue.)
There have been no changes to kalarm between 24.12.1 and 24.12.2 which would in any way affect session restoration, so it seems that it must be some external software change which has triggered the crash. When I tested kalarm master on the latest Neon, it didn't crash. It may be something dependent on the user's system configuration or other running software which is causing the issue. Could you please attach your kalarm session file ~/.config/session/kalarm_10c9cd6e65000173925866800000030170017_1739306175_87705 (or whatever its name is now).
Created attachment 178314 [details] session file crashing kalarm This is a much older session file, but it also causes the crash when running `/usr/bin/kalarm -session 10c9cd6e65000170616931600000035740013_1706219604_438476`.
It also crashes with a completely empty session file. I built v24.12.1 and v24.12.0 and they also crash so it's not a (recent) regression in kalarm and since I use 24.12.x before it doesn't seem to be a bug in kalarm. The crash seems to happen in RemoteLogger::~RemoteLogger() (from Akonadi). This is a singleton that tries to self-destruct when the application is about to quit: https://invent.kde.org/pim/akonadi/-/blob/release/24.12/src/shared/akremotelog.cpp#L39 Maybe QLoggingCategory is already half destroyed when ~RemoteLogger runs. Although this doesn't happen when kalarm is quit after being started with `kalarm --tray`. Weird. Anyway. The question is why does kalarm seem to quit in the first place when it's session-restored? I have put a breakpoint in QCoreApplication::aboutToQuit. That gives: #0 QCoreApplication::aboutToQuit (this=0x694130, _t1=...) at /usr/src/debug/qtbase-everywhere-src-6.8.2/build/src/corelib/Core_autogen/include/moc_qcoreapplication.cpp:264 #1 0x00007ffff4fb5e15 in QCoreApplication::exit (returnCode=returnCode@entry=0) at /usr/src/debug/qtbase-everywhere-src-6.8.2/src/corelib/kernel/qcoreapplication.cpp:1574 #2 0x000000000050369c in KAlarmApp::quitIf (this=this@entry=0x694130, exitCode=exitCode@entry=0, force=force@entry=false) at /home/ingo/dev/kde/kalarm/src/kalarmapp.cpp:796 #3 0x000000000050993b in KAlarmApp::activateInstance (this=this@entry=0x694130, args=..., workingDirectory=..., outputText=outputText@entry=0x7fffffffd350) at /home/ingo/dev/kde/kalarm/src/kalarmapp.cpp:704 #4 0x0000000000459de4 in main (argc=<optimized out>, argv=<optimized out>) at /home/ingo/dev/kde/kalarm/src/main.cpp:76 I have added a few qWarnings to KAlarmApp::activateInstance to debug why kalarm quits. It seems quitIf thinks it should quit. 22:04:13.286 W default: KAlarmApp::activateInstance 22:04:13.286 W default: KAlarmApp::activateInstance - exitCode: 0 22:04:13.286 W default: KAlarmApp::activateInstance - if (firstInstance && !dontRedisplay && !exitCode) 22:04:13.286 W default: KAlarmApp::activateInstance - if (ResourcesCalendar::instance()) 22:04:13.286 W default: KAlarmApp::activateInstance - if (quitIf(exitCode >= 0 ? exitCode : 0)) Looks like there's no main window or no tray window. Maybe you have an idea.
What? In main() app->activateInstance() is called before app->restoreSession() and because app->activateInstance() return 0 kalarm exits before it even tries to restore the session. Am I missing something?
I've also realised that kalarm frequently exits with an error from KAlarmApp::activateInstance() before it does the session restoration. The only difference from your experience is that I haven't seen a crash - for me, it exits cleanly. The real issue is that it shouldn't be exiting. I'm investigating.
A fix has been applied to ensure that KAlarm doesn't exit without good reason in KAlarmApp::activateInstance() if session restoration is required. The fix will be in KAlarm version 3.10.3, which will be released in KDE Gear 24.12.3. Commit 041337fa91ae94cdeabcd48af933a9e7adf82d37. The crash only occurs when KAlarm exits prematurely, and could still occur if KAlarm exited due to an error at the same stage. As far as I can see, the crash, which is in the Akonadi RemoteLogger destructor, is outside KAlarm's control.