Bug 204011

Summary:	knotify crashes repeatedly, crash handler windows render desktop useless
Product:	[Frameworks and Libraries] Phonon	Reporter:	David Chamberlain <dc46and2>
Component:	KDE platform plugin	Assignee:	Matthias Kretz <kretz>
Status:	RESOLVED DUPLICATE
Severity:	crash	CC:	andresbajotierra, echidnaman
Priority:	NOR
Version:	4.3.0 (KDE 4.2.0)
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description David Chamberlain 2009-08-16 05:03:11 UTC

Version:            (using KDE 4.3.0)
OS:                Linux
Installed from:    Gentoo Packages

I log into KDE and I immediately get an endless flood of crash handler windows telling me that knotify has crashed.  I cannot do anything, not even log-out, because the crash handler windows keep stealing the focus.  The only way to stop the insanity is to switch to a virtual console and stop the display manager service.

I later realized that alsa didn't like a recent change I had made to .asoundrc. After fixing this, my desktop is usable again.  Although the bad .asoundrc is obviously my fault, it definitely should not have brought my desktop environment to it's knees like this.

1) Broken sound should not cause knotify to crash.
2) knotify should not keep restarting after it's crashed 100 times in the last 20 seconds.
3) The crash handler needs to be tamed, so multiple crashes don't render the entire desktop, including the crash handler itself, completely useless.

Steps to reproduce: Create a file named ".asoundrc" in your home directory with something random in it and restart KDE.

Comment 1 Dario Andres 2009-08-16 17:26:59 UTC

Mh, I think it is Phonon duty to parse this file , and it is probably failing there.

It is strange, as applications autorestarting from a crash should not show the Crash Handler dialog again.

A backtrace would be useful, but I guess it will be difficult to fetch.

Thanks

Comment 2 David Chamberlain 2009-08-16 19:52:30 UTC

I got the crash loop going again and then made /usr/bin/knotify non-executable from the virtual console.  This prevented knotify from continuing to restart and lets me interact with the crash handler windows.  I got this:

Application: KNotify (knotify4), signal: Aborted
[KCrash Handler]
#5  0x00007f95c9431205 in raise () from /lib/libc.so.6
#6  0x00007f95c9432723 in abort () from /lib/libc.so.6
#7  0x00007f95c942a229 in __assert_fail () from /lib/libc.so.6
#8  0x00007f95c29f1c5f in ?? () from /usr/lib64/libasound.so.2
#9  0x00007f95c3167d66 in ?? () from /usr/lib64/kde4/plugins/phonon_platform/kde.so
#10 0x00007f95c3167f78 in ?? () from /usr/lib64/kde4/plugins/phonon_platform/kde.so
#11 0x00007f95c31625e5 in ?? () from /usr/lib64/kde4/plugins/phonon_platform/kde.so
#12 0x00007f95c31626d7 in ?? () from /usr/lib64/kde4/plugins/phonon_platform/kde.so
#13 0x00007f95cb073849 in Phonon::GlobalConfig::audioOutputDeviceListFor () from /usr/lib64/libphonon.so.4
#14 0x00007f95cb073dca in Phonon::GlobalConfig::audioOutputDeviceFor () from /usr/lib64/libphonon.so.4
#15 0x00007f95cb06e984 in ?? () from /usr/lib64/libphonon.so.4
#16 0x000000000040d2e1 in _start ()

I can rebuild with debugging symbols if you want, but I figure a developer who probably already has debugging enabled should be able to reproduce this easy enough.

Comment 3 Dario Andres 2009-08-16 19:57:33 UTC

I bet this is related to bug 203108 / bug 203076; or bug 193179 (this matches the asound line assert)

Thanks

Comment 4 Jonathan Thomas 2009-12-16 15:05:23 UTC

I agree, this is most probably bug 193179.

*** This bug has been marked as a duplicate of bug 193179 ***