Bug 468640

Summary:	KAlarm crashes after being up for a while, seems to suffer heavy lag a lot of the time
Product:	[Applications] kalarm	Reporter:	Gabriel Ravier <gabravier>
Component:	general	Assignee:	David Jarvie <djarvie>
Status:	RESOLVED FIXED
Severity:	crash	Keywords:	drkonqi
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:	https://invent.kde.org/pim/kalarm/-/commit/ef7c3e328a7f42f00acd94b75b51ad9d503e6a8e	Version Fixed In:	23.04.3
Sentry Crash Report:

Description Gabriel Ravier 2023-04-18 09:42:56 UTC

Application: kalarm (3.5.4.2 (KDE Gear 22.12.3))

Qt Version: 5.15.8
Frameworks Version: 5.104.0
Operating System: Linux 6.2.9-200.fc37.x86_64 x86_64
Windowing System: Wayland
Distribution: "Fedora release 37 (Thirty Seven)"
DrKonqi: 5.27.4 [KCrashBackend]

-- Information about the crash:
I've been observing KAlarm crashing very frequently (something like once a day or so on average).

Sometimes before it crashes I'll observe incredibly heavy lag (as in, very very visible audio stuttering issues on the alarms themselves).

The fact I have a lot of regular alarms scheduled might be related, but I don't think it's an excessive amount of them or anything like that.

The crash can be reproduced sometimes.

-- Backtrace:
Application: KAlarm (kalarm), signal: Aborted

[KCrash Handler]
#4  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#5  0x00007ff03e4afec3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#6  0x00007ff03e45fa76 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#7  0x00007ff03e4497fc in __GI_abort () at abort.c:79
#8  0x00007ff03c99aef8 in g_assertion_message (domain=domain@entry=0x0, file=file@entry=0x7ff03ef98002 "../src/pulse/glib-mainloop.c", line=line@entry=121, func=func@entry=0x7ff03ef98490 "cleanup_io_events", message=message@entry=0x5597f60d4930 "assertion failed: (g->io_events_please_scan == 0)") at ../glib/gtestutils.c:3256
#9  0x00007ff03c9fb86e in g_assertion_message_expr (domain=0x0, file=0x7ff03ef98002 "../src/pulse/glib-mainloop.c", line=121, func=0x7ff03ef98490 "cleanup_io_events", expr=<optimized out>) at ../glib/gtestutils.c:3282
#10 0x00007ff03ef969b5 in cleanup_io_events () at /lib64/libpulse-mainloop-glib.so.0
#11 0x00007ff03ef975b7 in prepare_func () at /lib64/libpulse-mainloop-glib.so.0
#12 0x00007ff03c9d1829 in g_main_context_prepare (context=0x7ff024005010, priority=0x7fff056c5058) at ../glib/gmain.c:3774
#13 0x00007ff03ca27f03 in g_main_context_iterate.constprop.0 (context=0x7ff024005010, block=1, dispatch=1, self=<optimized out>) at ../glib/gmain.c:4228
#14 0x00007ff03c9cef00 in g_main_context_iteration (context=0x7ff024005010, may_block=1) at ../glib/gmain.c:4313
#15 0x00007ff03ecee616 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x5597f5d8a1d0, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#16 0x00007ff03ec9bf3a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7fff056c51b0, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#17 0x00007ff03eca4002 in QCoreApplication::exec() () at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#18 0x00005597f4855bd4 in main ()
[Inferior 1 (process 3756957) detached]

Reported using DrKonqi

Comment 1 Gabriel Ravier 2023-04-18 09:46:56 UTC

PS: This particular crash occurred in the middle of an alarm, but I don't recall it being a required factor for KAlarm to crash, I've seen it crash without having any alarms occurring at any nearby time too.

Comment 2 David Jarvie 2023-04-18 11:13:45 UTC

That crash occurs in the Pulse Audio library,  which doesn't give any clue as to what's going wrong in KAlarm. Can you provide any other crash traces from when no alarm is underway?

Comment 3 Gabriel Ravier 2023-04-18 11:15:45 UTC

I'll try to get more of them, but it might take some time to do so given the crashes are closer to being daily than being hourly

Comment 4 David Jarvie 2023-04-28 11:04:38 UTC

I can see that there is a small memory leak when alarms trigger. This will not matter initially,  but after a large number of alarms,  it could start to slow KAlarm and eventually cause it to crash.

The leak is in memory allocated by setCustomProperties(), and needs further investigation to find out why. Hopefully this will be fixed for the next release.

Comment 5 Bug Janitor Service 2023-05-09 16:53:08 UTC

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kcalendarcore/-/merge_requests/149

Comment 6 David Jarvie 2023-05-09 16:55:53 UTC

It turns out that every time an alarm is displayed, a copy of the alarm is stored by the KCalendarCore library from KDE Frameworks. The library currently does not provide any way of disabling this unwanted behaviour. I have raised a merge request for a change which would allow this to be disabled.

Until that change is approved, the only way to avoid this bug is to quit KAlarm from time to time, and restart it. To quit KAlarm, you need to use the File -> Quit menu option when there are no alarm windows displayed. Alternatively, you can open a terminal window and enter the command 'killall kalarm' (without the quotes), and the alarm windows will be redisplayed when you restart it.

The problem feature in KCalendarCore will be removed when KDE migrates to Qt6, so this bug should be resolved then in any case.

Comment 7 David Jarvie 2023-06-05 23:28:53 UTC

I've now implemented a workaround to fix the bug, which will clear the memory leak whenever all alarm windows are closed. Note that if you always keep at least one alarm displayed, this fix will not work.

The proper fix would be in KCalendarCore library, as explained in comment 6, but that has not yet been approved. As also stated, the future Qt6 based version will not have this bug.

The workaround will be in KAlarm version 3.5.6 in KDE Apps 23.04.3, and is implemented by commit ef7c3e328a7f42f00acd94b75b51ad9d503e6a8e.