| Summary: | Every time notebook start with a Mageia 1 KDE, the window error appears kdeinit4 PID 1265 Sinal: Aborted (6) | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | Macxi <terraagua> |
| Component: | kded | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | crash | CC: | andresbajotierra, cfeck, sitter, xeyefo9277 |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Mageia RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Macxi
2011-07-25 00:24:23 UTC
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. *** |