GNOME Bugzilla – Bug 134775
gnome-settings-daemon crashes on login
Last modified: 2004-12-22 21:47:04 UTC
I am running control-center 2.5.3 on an iBook. When I log into GNOME, gnome-settings-daemon immediately crashes. It crashes several times and then GNOME deceides to stop trying to exec it. Here is the backtrace: (gdb) ba
+ Trace 44333
Fix this with: mknod /dev/pmu c 10 154 chmod 666 /dev/pmu *BUT* not having /dev/pmu should obviously not cause gnome-settings-daemon to crash.
Michael: are you seeing this with gnome-session 2.5.5 and the latest bonobo* releases still? I'm marking this a 2.6.0 showstopper, it's gruesome if it is still there.
This bug still seems to exist when using the following: control-center 2.5.3 gnome-session 2.5.90 libbonobo 2.5.4 libbonoboui 2.5.3
I know, this may sound silly - but I cured similar crash by explicit including the gstrfuncs.h file: #include <glib/gstrfuncs.h> Could you please try it - it is not that hard after all.
*** Bug 136704 has been marked as a duplicate of this bug. ***
Sergey, Where are you proposing including it explicitly? What C file?
Oh, also Michael, is that the whole stack? Could you include it up to main?
Ok. Looking at the code more, I see that this could only possibly happen on a PPC box. Michael, if you're not on PPC, let us know. Therefore, I'm going to add to OS Details. My guess as to what's happening is that starting that dialog while still in bonobo activation code causes reentrancy in bonobo activation which breaks.
Chris: gnome-settings-multimedia-keys.c. But not sure it would help. Just something which helped me once:)
Chris : agreed. The pmu warning is entering a main loop that borks bonobo. The simplest solution here is to jsut show the dialog, rather than running a main loop.
I tried this by adding an uncondition dialog. This crashed it. Having the dialog called in an idle handler fixed it. I've made this change to the code but am not on PPC so can't actually test this patch. I'm as confident about it as I can be given those conditions.
Created attachment 25705 [details] [review] idle the error dialog.
I reproduced the bug on the 2.5.4 package. Could I know why acme is trying to access rw on a device that is commonly marked readonly?
Applied a simple solution that avoids a recusive main loop by just having the error show, rather than using dialog_run. The device is accessed to provide brightness information and the crash was happening because the warning dialog was breaking the main loop.