GNOME Bugzilla – Bug 161960
Panel on 2nd screen crashes when using crux
Last modified: 2005-07-24 21:16:49 UTC
Steps to reproduce: System: SunFire V250 SPARC running Solaris 9 Gnome: 2.8.1 Blastwave.org package Panel: 2.8.2 I have a dual screen setup using two XVR-100 graphic cards. I start a separate Gnome 2.8.1 session on each screen. (This was not working at all in the previous Gnome 2.6 release but does appear to work OK now.) I have a single panel on each screen. I can use and modify the panel on the primary desktop without problem. The panel on the 2nd screen has the standard Applications and Actions menus and I can successfully launch any application from these menus without problem. However,if I attempt to modify the panel on the 2nd screen, the panel application appears to crash. For example, if I select Add To Panel, the Add To Panel window appears on the 2nd screen briefly and then disappears. The Panels on both screens disappear and then reappear. Any unsaved changes made to the panel on the 1st screen will have been lost. This repeats consistently. Has Gnome 2.8 been tested with a dual-screen setup? I tested this by creating a brand new user account. I first started Sun's Gnome 2.0.2 desktop to create a skeleton setup. I then started the Gnome 2.8.1 desktop. Other than this problem, 2.8.1 looks like a significant improvement. I would really like to get this problem resolved so that I can use this version. Stack trace: Other information:
Hi Jeff, > Has Gnome 2.8 been tested with a dual-screen setup? It's a good question :-) It seems a lot of developer would like to be able to test a multiscreen GNOME but are not able to do so... (at least, I) Could you obtain a stack trace of the crash? See http://bugzilla.gnome.org/getting-traces.cgi Thanks
I have bug-buddy installed but get nothing from it when gnome-panel fails. I also get no core dump.
Jeff: could you do this? + Run GNOME. + Open a terminal. + Run 'gnome-session-remove gnome-panel'. The panel should be removed. + Run 'gdb gnome-panel'. The panel should reappear. + Reproduce the bug. + In gdb, once the crash has happened, type 'bt'.
Hmm, I also am experiencing this bug, and tried the exact gdb steps above and cannot get my usual scenario to fail! Will keep trying other combinations
Peter: does bug-buddy gives you a stack trace when the panel crashes?
I tried to follow the instructions and trued to terminate the gnome-panel. Here are my results: 1-> gnome-session-remove gnome-panel (gnome-session-remove:7332): GnomeUI-WARNING **: While connecting to session manager: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed. Error: could not connect to the session manager I get this same result running as my normal login or as root.
Jeff: that's not normal (except if you ran this outside of GNOME), but we can do it in another way. Just repeat the command "killall gnome-panel" quickly a few times. You should end up with no panel. Then you can continue the instructions :-)
OK, here is some info to chew on. I killed all gnome-panel processes and: ------------------------------------------------------------------------------- 1-> gdb gnome-panel (no debugging symbols found)...(gdb) r Starting program: /opt/csw/bin/gnome-panel (no debugging symbols found)...(no debugging symbols found)...[etc, etc, etc] ------------------------------------------------------------------------------- NOTE: At this point I right-click on the panel on the 2nd screen and select "Add to Panel". The "Add to the panel" window pops up and the following occurs: ------------------------------------------------------------------------------- The program 'gnome-panel' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 1511 error_code 8 request_code 56 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Program received signal SIGPIPE, Broken pipe. 0xfda20040 in _writev () from /usr/lib/libc.so.1 (gdb) bt
+ Trace 54183
After exiting gdb, I restarted gnome-panel manually from within an xterm. It starts, but displays the following: 2-> gnome-panel (gnome-panel:18366): GnomeUI-WARNING **: While connecting to session manager: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed. Any clue what is wrong regarding this authentication error? Is there some problem with the way the Blastwave gnome package is being compiled that is keeping the panel and window manager form communicating properly? -------------------------------------------------------------------------------
Jeff: thanks for your help. This is becoming interesting... I have some questions: + I see you're using the crux theme (or at least a theme that uses the crux engine). Does the crash happen when you use another theme (simple, e.g.)? + could you run the panel with --sync (use 'set args --sync' in gdb) and copy the stack trace here? + do you know if it's possible to have Blastwave packages with better debugging symbols? It's not necessary, but it might be helpful. As for the authentication error, I admit I have no clue at all why this is happening. Is it specific to the panel or do other GNOME programs launch from xterm exhibit the same behaviour?
You hit one problem! The Crux theme is causing the crash. I tried all of the other stock themes and none of them cause a crash. I use the Bright frames and Default widgets in Sun's Gnome 2.0, although I remember trying Crux a long time ago and it didn't cause any problems. The theme mechanism has changed in 2.8 so I guess I just ended up with Crux by default. So I switched to another theme and now had the opportunity to observe new problems. I can now place a drawer on the 2nd screen toolbar. However, when you try to modify its properties, display the pull-down panel or launch an application from the drawer's panel, evetything gets displayed on screen #1. If you launch gnome built-in applications from the menus (such as the desktop preference applications) these windows do properly display on screen #2. This is a serious problem. Another less serious problem unrelated to the gnome-panel has to do with icon selection from a properties window. If you click on the icon button the icon selection panel displays. If you then click the Browse button the browse window is displayed. Select an icon and it should be immediately placed on the properties window (as in Gnome 2.0), but in this case, you are returned to the original icon selection window and must click again on OK to get back to the properties window. This is annoying. It is also very annoying that Gnome cannot remember where all windows are placed (xterms, etc.) on all desktops and screens when the "Save Current Setup" is performed. I did try to run other gnome applications manually (i.e., gnometris, gnome-stones, etc.) and they produced the same authentication error message previously reported for gnome-panel. To help out your debugging, I did reselect the Crux theme and ran gnome-panel with the --sync argument. Here are the results: ------------------------------------------------------------------------------- 2-> gdb gnome-panel (no debugging symbols found)...(gdb) set args --sync (gdb) r Starting program: /opt/csw/bin/gnome-panel --sync (no debugging symbols found)...(no debugging symbols found)... ............. The program 'gnome-panel' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 4595 error_code 8 request_code 56 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Program received signal SIGSEGV, Segmentation fault. 0xfdef4a3c in ORBit_handle_request () from /opt/csw/lib/libORBit-2.so.0 (gdb) bt
+ Trace 54186
Vincent, thanks for your help. I hope this info is helpful in getting these issues resolved.
> You hit one problem! > > The Crux theme is causing the crash. I tried all of the other stock themes and > none of them cause a crash. I use the Bright frames and Default widgets in > Sun's Gnome 2.0, although I remember trying Crux a long time ago and it didn't > cause any problems. The theme mechanism has changed in 2.8 so I guess I just > ended up with Crux by default. So I switched to another theme and now had the > opportunity to observe new problems. Great! We'll move the bug to gnome-themes, then. > I can now place a drawer on the 2nd screen toolbar. However, when you try to > modify its properties, display the pull-down panel or launch an application from > the drawer's panel, evetything gets displayed on screen #1. If you launch gnome > built-in applications from the menus (such as the desktop preference > applications) these windows do properly display on screen #2. This is a serious > problem. This is probably bug #114842. You might want to add yourself to the cc field of this bug. > Another less serious problem unrelated to the gnome-panel has to do with icon > selection from a properties window. If you click on the icon button the icon > selection panel displays. If you then click the Browse button the browse window > is displayed. Select an icon and it should be immediately placed on the > properties window (as in Gnome 2.0), but in this case, you are returned to the > original icon selection window and must click again on OK to get back to the > properties window. This is annoying. This is a bug in libgnomeui. You should open a new bug against libgnomeui. > It is also very annoying that Gnome cannot remember where all windows are placed > (xterms, etc.) on all desktops and screens when the "Save Current Setup" is > performed. If you use gnome-terminal and not xterm, I think this should work.
gnome-themes guys: Jeff is really helpful, so don't hesitate to ask for more informations!
I've been silently suffering this problem for a while, but it's recently started annoying me again. I've done a bit of poking around and I think I've figured out what's going on here. It appears to be a GDK pixmap creation problem, with enough things masking it that it sort of looks like it's the panel's fault, or the theme's fault if you look a bit closer. Apps that draw to multiple X11 screens aren't very common (gnome-panel is about the only one I can think of, besides WMs), and nor are multi-screen (non-Xinerama) setups on which they can do so. The crux theme uses gdk_pixbuf_render_pixmap_and_mask() to create pixmaps with which to draw widgets (I think it's the scrollbar in the 'add to panel' dialog that actually triggers it, but if it wasn't that, it'd be something else). gdk_pixbuf_render_pixmap_and_mask() calls gdk_pixbuf_render_pixmap_and_mask_for_colormap() using the colormap returned by gdk_rgb_get_colormap(), which associated with the default screen. gdk_pixbuf_render_pixmap_and_mask_for_colormap() creates the target pixmap, passing into gdk_pixmap_new() the root window for the screen associated with the colormap.. which isn't the right screen in this case. When something attempts to use that pixmap to render to a drawable for a non-default screen, the source drawable doesn't match the target, so we get a BadMatch error (XCopyArea(3X11) says "If the drawables do not have the same root, a BadMatch error results."). The actual crash appears to happen in a broken cleanup handler or something. I'm fairly certain that fixing the BadMatch error will hide that bug for a bit longer. For what it's worth, the investigation resulting in the above was done using source packages from debian unstable (gtk+ 2.6.2, gnome-themes 2.8.2), as that's where I'm experiencing the problem. Assuming all the above is correct, it looks like the only to fix it is to pass an 'eventual target' drawable in to gdk_pixbuf_render_pixmap_and_mask() so it can create a pixmap for the right screen. (apologies if I'm mixing up terms here; I'd never looked at any of this code before today, and I know just enough about X11 programming to confuse myself and others)
Created attachment 37628 [details] [review] Proposed fix Alternatively, here's a patch (against gnome-themes 2.8.2). It doesn't fix the gdk_pixbuf_render_pixmap_and_mask() being non multihead safe, but it does get multiheaded crux-themed gnome-panels working for me. I haven't tested it extensively, though.
The engines now live in gtk-engines module, re-assigning.
Looks like a reasonable patch. Can anyone with a dual screen setup test it against the latest gtk-engines and confirm?
I tested the proposed patch, and it fixes the crash. The tested setup is a dual head radeon 9200 with xinerama (on x86).
Committed the proposed patch. Marking as fixed.