gnome-panel crashes on unknown gid

Thanks for your bug. That's rather a misconfiguration than a software bug.
Probably due to the gnome-menus patch, Ccing Emmanuel who works on this.

The warning comes from gnome-menus' patch (user_is_sudoer () runs "group
<user>") but that's just a normal warning, it doesn't crash the panel. Can you
get a backtrace of the crash (the bug-buddy dialog to send a bug upstream has
it)? Out of this message that works fine for me.

I had this problem too, as /home was on NFS and only a couple of the UID/GIDs
used in /home were in the local lists

Oddly it crashes on my family's near default configs and on blank newly-created
accounts, but not on my own heavily customised one -- I have yet to find out
which change it is that I've made that lets my gnome-panel not crash :/

This backtrace was made by waiting for GP to crash, opening nautilus from a
desktop link, opening gnome-session-properties and setting GP to "normal" rather
than "restart", then manually running GP inside GDB from a gnome-terminal -- I
had been waiting for it to crash then doing GDB attaches to `pidof gnome-panel`,
but the stack was often mangled by the time I got to it

GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library
"/lib/tls/i686/cmov/libthread_db.so.1".

(gdb) run
Starting program: /usr/bin/gnome-panel
[Thread debugging using libthread_db enabled]
[New Thread -1223719232 (LWP 8916)]

** (gnome-panel:8916): WARNING **: Failed to lock: No locks available

** (gnome-panel:8916): WARNING **: Failed to lock: No locks available
id: cannot find name for group ID 1003
[New Thread -1224459344 (LWP 8922)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223719232 (LWP 8916)]
0xb7670af1 in strstr () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7670af1 in strstr () from /lib/tls/i686/cmov/libc.so.6
#1 0xb78664bb in IA__g_strsplit (string=0x65207370 <Address 0x65207370 out of
bounds>,
    delimiter=0xb7ea40d8 " ", max_tokens=2147483647) at gstrfuncs.c:2186
#2 0xb7ea18da in gmenu_tree_directory_make_path () from /usr/lib/libgnome-menu.so.2
#3 0xb7e95859 in ?? () from /usr/lib/libgnome-menu.so.2
#4 0x0820d5b0 in ?? ()
#5 0xb7ea19d3 in ?? () from /usr/lib/libgnome-menu.so.2
#6 0xb7ea1a3c in ?? () from /usr/lib/libgnome-menu.so.2
#7 0x00000000 in ?? ()
#8 0x00000000 in ?? ()
#9 0xb7731900 in __malloc_initialize_hook () from /lib/tls/i686/cmov/libc.so.6
#10 0xfffffff0 in ?? ()
#11 0xbfe8a618 in ?? ()
#12 0xb766b391 in malloc () from /lib/tls/i686/cmov/libc.so.6
#13 0xb7e966d2 in ?? () from /usr/lib/libgnome-menu.so.2
#14 0x0820d4d8 in ?? ()
#15 0xffffffff in ?? ()
#16 0x0000001f in ?? ()
#17 0xb7ea520c in ?? () from /usr/lib/libgnome-menu.so.2
#18 0xb7ea520c in ?? () from /usr/lib/libgnome-menu.so.2
#19 0x0820f15f in ?? ()
#20 0xbfe8a6e8 in ?? ()
#21 0xb7e97491 in ?? () from /usr/lib/libgnome-menu.so.2
#22 0x0820f15f in ?? ()
#23 0xb7ea1acc in ?? () from /usr/lib/libgnome-menu.so.2
#24 0x0820dc88 in ?? ()
#25 0xb7853f7e in IA__g_malloc0 (n_bytes=136370792) at gmem.c:154
Previous frame inner to this frame (corrupt stack?)
(gdb) quit
The program is running. Exit anyway? (y or n)

This is most probably http://bugzilla.gnome.org/show_bug.cgi?id=313453

Does it still happen?

(In reply to comment #4)
> This is most probably http://bugzilla.gnome.org/show_bug.cgi?id=313453
>
> Does it still happen?

Using an up-to-date Breezy gnome-panel still crashes if I just change my gid in
/etc/passwd to an unexisting one. Just do the following:
 - edit /etc/passwd and change your gid to 1009 (or something)
 - killall gnome-panel - gnome-panel restarts but crashes
 - change /etc/passwd back to what it was
 - restart gnome-panel and it doesn't crash anymore

Would that really be considered a bug ? I agree that crashing shouldn't happen,
in any case, but doing random changes, as root, to configuration files is
deliberately looking for trouble... Isn't it ? I'm sure I can make a lot of
things crash if I edit /etc/passwd wrongly :)

(In reply to comment #6)
> Would that really be considered a bug ? I agree that crashing shouldn't happen,

Given that crashing shouldn't happen, and crashing does happen, I'd say "yes,
it's a bug" :P

> in any case, but doing random changes, as root, to configuration files is
> deliberately looking for trouble... Isn't it ? I'm sure I can make a lot of
> things crash if I edit /etc/passwd wrongly :)

My crash happened through mounting /home over NFS, and some of the groups on the
server weren't mirrored on the client. I'd assume that a more common thing to do
than random config file changes, but config file editing just happens to be an
easy way to demonstrate the problem...

> Given that crashing shouldn't happen, and crashing does happen, I'd say "yes,
> it's a bug" :P

Right, looks like I trapped myself in there :)

> My crash happened through mounting /home over NFS, and some of the groups on the
> server weren't mirrored on the client. I'd assume that a more common thing to do
> than random config file changes, but config file editing just happens to be an
> easy way to demonstrate the problem...

I see. Anyway, this seems to be an upstream bug and probably doesn't come from
my (rewritten by Sebastien) gnome-menus Ubuntu patch, as we thought at first.

Could you install the gnome-panel-dbg, libgtk2.0-0-dbg and libglib2.0-0-dbg
packages and attach a new stack trace?

Thanks

Hi Vincent,

(In reply to comment #9)
> Could you install the gnome-panel-dbg, libgtk2.0-0-dbg and libglib2.0-0-dbg
> packages and attach a new stack trace?

I've done that, but I don't get a stack trace. Even if I run gnome-panel with
--disable-crash-dialog (and I still get the crash dialog).

This is the only output:

  taco@cambyses:~ $ gnome-panel --disable-crash-dialog
  id: cannot find name for group ID 1009

I've also done the above with strace and the output is attached.

Created an attachment (id=5587)
strace output of gnome-panel --disable-crash-dialog

Oh, sorry, I should have told you that you should look for the wnck-applet
program (it's installed in /usr/lib/gnome-panel)

(In reply to comment #12)
> Oh, sorry, I should have told you that you should look for the wnck-applet
> program (it's installed in /usr/lib/gnome-panel)

Hmm, I'm not sure what I should see, but I've done this:

  taco@cambyses:/usr/lib/gnome-panel $ killall wnck-applet
  taco@cambyses:/usr/lib/gnome-panel $ ./wnck-applet

  (wnck-applet:10605): Wnck-CRITICAL **: wnck_screen_get_windows: assertion
`WNCK_IS_SCREEN (screen)' failed

  (wnck-applet:10605): Wnck-CRITICAL **: wnck_screen_get_active_window:
assertion `WNCK_IS_SCREEN (screen)' failed

If I do this with the notification-area-applet I get no output.

(In reply to comment #13)
> Hmm, I'm not sure what I should see, but I've done this:
>
> taco@cambyses:/usr/lib/gnome-panel $ killall wnck-applet
> taco@cambyses:/usr/lib/gnome-panel $ ./wnck-applet
>
> (wnck-applet:10605): Wnck-CRITICAL **: wnck_screen_get_windows: assertion
> `WNCK_IS_SCREEN (screen)' failed
>
> (wnck-applet:10605): Wnck-CRITICAL **: wnck_screen_get_active_window:
> assertion `WNCK_IS_SCREEN (screen)' failed

Taco: does it crash? If yes, can you use gdb to get a stack trace?

(In reply to comment #14)
> (In reply to comment #13)
> > Hmm, I'm not sure what I should see, but I've done this:
> >
> > taco@cambyses:/usr/lib/gnome-panel $ killall wnck-applet
> > taco@cambyses:/usr/lib/gnome-panel $ ./wnck-applet
> >
> > (wnck-applet:10605): Wnck-CRITICAL **: wnck_screen_get_windows: assertion
> > `WNCK_IS_SCREEN (screen)' failed
> >
> > (wnck-applet:10605): Wnck-CRITICAL **: wnck_screen_get_active_window:
> > assertion `WNCK_IS_SCREEN (screen)' failed
>
> Taco: does it crash? If yes, can you use gdb to get a stack trace?

Sorry, it doesn't crash (hmm, a bit strange to want something to crash but ok
;-) ). I can send ~/.xsession-errors but it doesn't really contain new
information about this. There's nothing in my logfiles either. Can I try
something else?

(In reply to comment #15)
> (In reply to comment #14)
> > Taco: does it crash? If yes, can you use gdb to get a stack trace?
>
> Sorry, it doesn't crash (hmm, a bit strange to want something to crash but ok
> ;-) ). I can send ~/.xsession-errors but it doesn't really contain new
> information about this. There's nothing in my logfiles either. Can I try
> something else?

If it doesn't crash, then it's not the same issue (and it's not really an issue) :-)

(In reply to comment #16)
> If it doesn't crash, then it's not the same issue (and it's not really an
issue) :-)

Well, ok, maybe it's not a very important issue but I still think gnome-panel
could react nicer (an unsuspecting user wouldn't be able to solve this problem
because the crash window doesn't give any clue that the problem might be related
to /etc/passwd|group and I think gnome-panel could be able to start without
every group having a name). Feel free to mark it LATER.

Do you still have that problem?

The problem seems to be solved. In the same situation, the panel works without any problem.

marking fixed then, thank you for the update