Bugzilla – Bug 104161
gnome apps hard-coded in session (netapplet, best) often crash at login
Last modified: 2005-08-29 14:54:45 UTC
We're starting netapplet and best at login, hard-coded in gnome-session (ick, ick, ick). They're both often crashing at login, but not at other times. I suspect the cause is similar, though it's perhaps worth noting that resapplet (same situation) hasn't been crashing. I'm going to attach a netapplet stack trace, for which purpose I had installed gtk2-debuginfo, glib2-debuginfo, and netapplet-debuginfo. It's hard to get similar data from best.
Created attachment 45795 [details] netapplet stack trace w/ symbols
Also worth noting that starting the apps via proper session management does not cause a crash. Nor does running them when the panel is not running. Restarting the apps always works. Only the start on load crashes, and not even every time.
I have tried to add it to default session with 9.3. It should be simple to do. But I did not get it restarted after crash (and people having old session saved from old SuSE version will not start it, too). For SuSEplugger and SuSEwatcher it is not a solution, because they doesn't support --sm-config-prefix.
*** Bug 104216 has been marked as a duplicate of this bug. ***
I think the cause of the crash is the notification area not being started yet, so netapplet and others fail adding the icon to the system tray. Maybe we might want to add a timeout so that we don't start all those applications a few seconds after all applications in the session have been started?
Gary's already done that, with a 2 second delay - really the eggicontray code should be a bit more robust though, and probably busy wait until the tray becomes available.
Is it only SUSE which suffers from this problem? A solution without unreliable sleep calls would definitely be preferable.
Well, we're patching gnome-session to launch several apps (susewatcher, netapplet, best, resapplet, etc.) by default, even on upgrade from an existing session, by hard-coding those apps (by name) into the session. The patch is SUSE-specific, and we suspect it's exposing a race which is not readily visible otherwise. The patch itself is admittedly a horrible, gross, ugly hack. We're working on an upstream replacement (based on .desktop files, modeled after KDE functionality, last I looked), but it's not going to be ready for Gnome 2.12, so we're stuck with horrible, gross, and ugly for this release. Ideally, as JP notes, we should find a less hackish solution to these crashes than an arbitrary delay. The delay is a stopgap fix to a stopgap solution. It's also one that doesn't work perfectly; I'm still seeing netapplet crashes, though I haven't had best crash on me. Perhaps the delay in parsing the "--autostarted" argument (which is, alas, interpreted as a query in beta2) is delaying its appearance enough to prevent it from crashing. :-/
*** Bug 104650 has been marked as a duplicate of this bug. ***
Is that possible we use ~/.gnome2/session to lauch apps like susewatcher or resapplet? Hardcode these apps into gnome-session is too intrusive. I have to remove the patch and rebuild gnome-session everytime I upgrade my system, which is boring.
It's certainly possible for users to add or remove things from their sessions (modulo the inability to remove hard-coded things), but there's no good way for administrators to add something to existing users' sessions. Gnome is currently missing that functionality. One alternative to rebuilding gnome-session is to rename the apps that you don't want started in your session and replace them with symlinks to /bin/true. This works for suseplugger, for example. It doesn't work so well with netapplet, though, which for security reasons won't function properly if it's called something else.
We currently have a work around for the crash, but its less than ideal.
Downgrading to major because of the work around. Federico, any clues here?
See the stack trace in comment #1, look at frame 5, and notice the following: - src_buf and dest_buf are the same - this is wrong. - width is a huge number - this is wrong. - src_buf looks like a pointer to static, read-only memory. Since the source pixbuf is *probably* a stock icon, this makes sense. I'd like to see the values of variables in frame 6, as well as the contents of "image". Is _gdk_image_get_scratch() returning an image structure with garbage?
BTW, the trace doesn't indicate that this has anything to do with race conditions in gnome-session. The widget is already mapped, as it is processing an expose event - at that point, the session machinery is well out of the way.
I get a totally different stack trace.
Created attachment 47464 [details] Best crash stacktrace.
Chris, is it possible to get the stack trace again with --sync?
Created attachment 47668 [details] Best crash stacktrace with --sync
I experienced the same problems with beta3 clean install: First gnome session had tons of issues, netapplet, gnome-volume-manager, resapplet all quit unexpectedly and forced me to restart gnome session (gnome-session-manager proc 12453 has crashed... segmentation fault). This happened twice until I selected gnome in the session list (it was Last, but there was no last :) cause was first session ever started... so prolly this could have been the problem). These applets still are not loaded, even though I managed to start a gnome session. Loading them manually works though... On top of this, the weather report applet crashes often, requesting to be restarted... with no obvious reason to it... Daniel
Hacky work around removed. Fixed with upstream gtk 2.8.2.