Bug 104161

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.