Application: kded4 ($Id$) KDE Platform Version: 4.6.3 (4.6.3) Qt Version: 4.7.3 Operating System: Linux 2.6.38.8-desktop586-4.mga i686 Distribution: "Mageia 1" -- Information about the crash: - What I was doing when the application crashed: Every time I start the notebook (Compac Presario C750) with a Mageia 1 KDE, a window error appears: "Details: Executable: kdeinit4 PID 1265 Sinal: Aborted (6)" - Unusual behavior I noticed: This only occurs in a notebook, does not occur on other computers. I close the window and a Mageia works normally. But that window come back every time I restart the computer. I created a new user and and the window with error appears again. I renamed the folder .kde4 and restart the computer and he window with error appears again. - Custom settings of the application: No special configuration effects on the desktop is disabled 3D effects disabled. Setting a standard KDE Mageia Bug reported in Mageia Forum: https://forums.mageia.org/en/viewtopic.php?f=7&t=830 The crash can be reproduced every time. -- Backtrace: Application: Serviço do KDE (kdeinit4), signal: Aborted [KCrash Handler] #7 0xffffe430 in __kernel_vsyscall () #8 0xb5faf181 in raise () from /lib/i686/libc.so.6 #9 0xb5fb0cae in abort () from /lib/i686/libc.so.6 #10 0xb5fa7a98 in __assert_fail () from /lib/i686/libc.so.6 #11 0xaf1af061 in snd_hctl_handle_events () from /usr/lib/libasound.so.2 #12 0xaf1bc4f1 in snd_mixer_handle_events () from /usr/lib/libasound.so.2 #13 0xaf280581 in ?? () from /usr/lib/kde4/kded_kmixd.so #14 0xaf298ebe in ?? () from /usr/lib/kde4/kded_kmixd.so #15 0xaf298e2e in ?? () from /usr/lib/kde4/kded_kmixd.so #16 0xb6e0c77d in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib/libQtCore.so.4 #17 0xb6e1bfac in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #18 0xb6e23165 in ?? () from /usr/lib/libQtCore.so.4 #19 0xb6e2321c in ?? () from /usr/lib/libQtCore.so.4 #20 0xb6e1b8f4 in QObject::event(QEvent*) () from /usr/lib/libQtCore.so.4 #21 0xb6304fb4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #22 0xb6309f97 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #23 0xb753e351 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5 #24 0xb6e05f2e in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4 #25 0xb6e379ab in ?? () from /usr/lib/libQtCore.so.4 #26 0xb6e34642 in ?? () from /usr/lib/libQtCore.so.4 #27 0xb5acd4d9 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #28 0xb5acdce0 in ?? () from /lib/libglib-2.0.so.0 #29 0xb5acdf9a in g_main_context_iteration () from /lib/libglib-2.0.so.0 #30 0xb6e34d9b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #31 0xb63bc7fa in ?? () from /usr/lib/libQtGui.so.4 #32 0xb6e0513d in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #33 0xb6e053b9 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #34 0xb6e09ef0 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #35 0xb6302d34 in QApplication::exec() () from /usr/lib/libQtGui.so.4 #36 0xb5071e2d in kdemain () from /usr/lib/libkdeinit4_kded4.so #37 0x0804dca4 in _start () Possible duplicates by query: bug 247807, bug 247040. Reported using DrKonqi
I observed that the error only occurs when the user initialization is automatic. If I restart the session and make access to the user again through login and password, the error doesn't occur, window with error doesn't appear..
*** This bug has been marked as a duplicate of bug 278455 ***
In Mageia Forum (https://forums.mageia.org/en/viewtopic.php?f=7&t=830#p5910) Djennings said: "If you only see the problem when using auto login then it could be related to speedboot. Mageia/Mandriva has a system called speedboot which attempts to load all the essential parts of the system as rapidly as possible while leaving non essential parts to be initialised later. Speedboot reduces boot times considerably, but can cause some anomalies. Try disabling speedboot as described here. ( http://wiki.mandriva.com/en/2010.0_Errata#Sometimes_you_may_see_anomalies_which_may_be_caused_by_speedboot )" I tested putting "speedboot=no" in the boot and the error doesn't occur in the automatically at startup. I opened a bug 2275 ( https://bugs.mageia.org/show_bug.cgi?id=2275 ) in Mageia Bugzilla.
Now that's interesting. So the real issue is that ALSA (sound) configuration isn't ready, when kded4 or kmix already tries to start. Adding Phonon maintainer to make sure he learns something new ;)
lol, interesting. so, I for one think that alsa should not crash, since the actual reason for the crash is a failing assert. presuming that kmix does not throw invalid input at libasound the assert there is probably just wrong, depending on what it actually does (I did not look at the ALSA source). Anyhow. I do consider this a non-issue in any KDE technology. In particular two things are very wrong with the whole situation: Speedboot should not speed into a desktop without having all components that are necessary for a desktop. Point being that it is probably less than trivial to recover applications *at runtime* from a start without sound devices. Meaning most of the time one would need to restart or logout&login to get everything working again. Which defeats the purpose of speedboot quite a bit. Now considering that the KDE workspace by default starts into the previously left session there could be a great number of apps that needed starting (aka time) and yet they'd be rendered partially unusable. So the user actually waited for nothing. Yay. The second problem is that ALSA should probably not crash. Unless ALSA is initializing right while kmix tries to start, the failing assert might be bogus the way it is. libasound certainly should not go down over not having whatever ALSA stuff that is not loaded yet. Of course this might still be bogus function call from kmix, but without looking at the code that is hard to say. Either way they should not crash.
[Comment from a bug report cleaner] - Is this report (and bug 278455) related to bug 209975 ?
*** Bug 279764 has been marked as a duplicate of this bug. ***