GNOME Bugzilla – Bug 320399
All Applications using GTK+ 2.8 Crash with 16-Bit visuals on Citrix Metaframe For Unix 1.2
Last modified: 2006-01-23 20:25:31 UTC
Please describe the problem: I apologize for not knowing where to place this bug. We built our first GTK 2.8 based GNOME server running Suse Linux 10. All GNOME/GTK applications crash when started from Citrix Metaframe For Unix via remote display. But, they only crash in 16 bit color. 32 bit color works fine. Citrix provides an Xserver running on Solaris and provides compression so that sites with lower bandwidth can access software. It's similar to tight-VNC. When you start up any GNOME application, you get this: oa3:~ # gedit The program 'gedit' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 1200 error_code 8 request_code 72 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.) oa3:~ # However, we have other 16 bit based thin clients that work just fine. gdb reported nothing and just said 'no trace' when I tried to get a backtrace. This leads me to believe that it's not even getting started at a very basic level and the program won't even start. oa3:~ # rpm -qa | grep gtk2 gtk2-themes-0.1-639 gtk2-engines-2.6.5-5 gtk2-doc-2.8.3-4 gtk2-devel-2.8.3-4 gtk2-2.8.3-4 Cairo was upgraded from the stock 1.0.0 to 1.0.2. Let me know how I can help. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Can you please add an app with --sync in gdb, break in gdk_x_error(), and see where you get the error from ?
I'm not that familiar with the steps you are describing, or I would have done it when I saw the error. :) I don't know how to use breakpoints. I tried another idea, and got a bit more information: (gdb) exec gedit --sync (gdb) run Starting program: /opt/gnome/bin/gedit (no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type <return> to continue, or q <return> to quit--- (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 1091849376 (LWP 15665)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) The program 'gedit' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 912 error_code 8 request_code 72 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 exited with code 01. (gdb) backtrace No stack. (gdb
that is because gdk_x_error calls exit(1) To get a backtrace, do gdb /usr/bin/gedit then at the gdb prompt, break gdk_x_error run and when it hits the breakpoint, do backtrace
(should probably be "run --sync" instead of just "run")
Tested as requested and it's still not reporting anything useful. That seems to indicate it's not even getting to the breakpoint? Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (gdk_x_error) pending. (gdb) run --sync Starting program: /opt/gnome/bin/gedit --sync (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 1091849376 (LWP 28300)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) The program 'gedit' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 1071 error_code 8 request_code 72 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 exited with code 01. (gdb) backtrace No stack. (gdb)
For your information: oa3:~ # xdpyinfo name of display: desktop_c:48.0 version number: 11.0 vendor string: Citrix Systems Inc vendor release number: 53034 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, MSBFirst, 32 image byte order: MSBFirst number of supported pixmap formats: 2 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 keycode range: minimum 8, maximum 207 focus: window 0x1400026, revert to PointerRoot number of extensions: 10 BIG-REQUESTS DOUBLE-BUFFER MIT-SHM MIT-SUNDRY-NONSTANDARD RECORD SECURITY SHAPE SYNC XC-MISC XTEST default screen number: 0 number of screens: 1 screen #0: print screen: no dimensions: 1440x1080 pixels (366x274 millimeters) resolution: 100x100 dots per inch depths (1): 16 root window id: 0x26 depth of root window: 16 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x22 default number of colormap cells: 64 preallocated pixels: black 0, white 32767 options: backing-store NO, save-unders NO largest cursor: 32x32 current input event mask: 0xfa203f KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask ButtonMotionMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals: 1 default visual id: 0x23 visual: visual id: 0x23 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0x7c00, 0x3e0, 0x1f significant bits in color specification: 8 bits
ping - Is there any leg work that I can do for this issue? This is a blocker for us to deploy any GTK 2.8 applications in our enterprise. We use Citrix Xservers in many sites.
It's time to build the GTK+ stack with debugging info, and retry the gdb stuff.
Ok, SL10 is back on the network with fresh install. I tested GTK 2.8 apps to make sure they crash and they still do in 16 bit color. I received instructions from Novell and installed the debuginfo packages and here is what was returned at the breakpoint. Let me know please if you need more information....it's very easy for me to replicate this. Starting program: /opt/gnome/bin/zenity --sync --info Breakpoint 2 at 0x4051cebd: file gdkmain-x11.c, line 599. Pending breakpoint "gdk_x_error" resolved Breakpoint 2, gdk_x_error (display=0x806adb8, error=0xbff9f4fc) at gdkmain-x11.c:599 599 if (error->error_code)
+ Trace 65110
Just to confirm, are the following accurate: 1. The app is running in an Intel server 2. The X server is running on a thin client What's the value of the $DISPLAY environment variable? Is the info for xdpyinfo you posted above still accurate? I'm puzzled that if you are running on a thin client (i.e. a remote X server), Gdk tries to use the X shared memory extension --- that's not available when running on a remote server.
The applications are running on Intel based Linux servers, yes. The Xserver isn't running on a thin client. The Xserver is started inside the Citrix session on a Solaris/Sparc machine and then Linux remote displays over. The reason why Citrix is used is because it does bandwidth compression of X to remote devices that don't have a high speed network by only transmitting pixels that change with high compression. The connection between the Linux and Sparc servers is gigabit fiber optic. It's a remote display, shared memory should not be used. linux:~ # echo $DISPLAY desktop_c:18.0 linux:~ # Each additional user comes from the same machine (desktop_c), but Citrix increments the middle number (18 in this case) with each new user that logs in. Let me know if running the same command in 8, or 32 bit would help to see what's different. Those color depths work fine.
Could you please attach the output of "xdpyinfo" for all the bit depths (8, 16, 24/32)? So GTK+ 2.6 works fine in 16 bpp, right?
Bad news about that. It appears that unpatched SL10 crashes in unrelated bugs in 8bit color depth. They must be fixed in the patches that go on after install. We didn't perform that step because I needed to have synced -debuginfo packages of glib and gtk2. So I guess we have to make a decision about whether additional 'debuginfo' is needed. If not, I'll put down all of the patches packages and get you the rest of the information. I'll try and locate debuginfo packages for all of the patches, they don't come with the distribution. GTK 2.6 and lower applications all work fine, many many years of service here. Here is what gedit is reporting on unpatched 8bit color, probably fixed and just needs to be upgraded:
+ Trace 65111
Latest build of GTK+ for SUSE Linux 10.0 is at http://primates.ximian.com/~pzb/gtk2-10.0/ This includes all the fixes in the released patches and the matching debuginfo package.
Cairo crashing on 8-bit pseudocolor visuals is a different bug. Let's stick to the 16bpp shared memory issue here. Can you please provide the output of "xdpyinfo" for all bit depths?
Federico, I think we always try to allocate a shared image first, and the turn off xshm if we get an error. See gdkimage-x11.c:342 So David, please continue there, and see what the next X error is.
We were just getting ready to install the patches when this came in, so let's do this first. I continued after the last breakpoint and then it stopped again and backtrace reported (gdb)
+ Trace 65132
Then a third 'cont' displays to the command line what I am seeing normally: (gdb) cont Continuing. The program 'gedit' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 1393 error_code 8 request_code 72 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 exited with code 01. (gdb)
Could you please install the debuginfo package for cairo as well, and re-run the test? Do the same thing; ignore the first call to gdk_x_error if it is from within XShmAttach.
Done: Breakpoint 2, gdk_x_error (display=0x80ca380, error=0xbfbe245c) at gdkmain-x11.c:599 599 if (error->error_code) (gdb) backtrace
+ Trace 65136
Created attachment 57173 [details] Requested, 8 bit color xdpyinfo for Citrix Metaframe for Unix (setting up 24 and 32 bit workstations how to get similar information)
Why is dst_y a huge number in frame 7?
All- I need some help in the best way to proceed with Metaframe and holding bug information. I have fully patched SL10 for the first time. I have just finished doing some additional testing with the Citrix Xserver with SL10/GTK 2.8. Cairo has been updated to 1.0.2. The results: 8 bit - GTK applications crash immediately with what appears to be Cairo errors. Those errors are different than 16bit. 16 bit - GTK applications crash immediately with the information posted in this bug report. 24 bit - GTK applications run, but are just horribly slow. They take a LONG time to open, and then a long time to repaint. The pulldowns take several seconds to paint, and then when you move to the next pulldown, the first pulldown leaves a ghost image on the screen for many seconds before the new one repaints. I tested GTK 2.6 and lower applications in all 3 depths and they work perfectly. We have all of these depths in production and would have noticed problems earlier. My question, should I break out 3 unique bugs...one for each color depth and go from there? I can then merge in the appropriate information that you have all helped me discover into the right color depths. It seems to me that we have 3 different issues, yet they are all related. I got the 24 bit xdpyinfo and attaching.
Created attachment 57284 [details] Requested, 24 bit color xdpyinfo for Citrix Metaframe for Unix
(In reply to comment #22) > 8 bit - GTK applications crash immediately with what appears to be Cairo > errors. Those errors are different than 16bit. > > 16 bit - GTK applications crash immediately with the information posted in this > bug report. > > 24 bit - GTK applications run, but are just horribly slow. They take a LONG > time to open, and then a long time to repaint. The pulldowns take several > seconds to paint, and then when you move to the next pulldown, the first > pulldown leaves a ghost image on the screen for many seconds before the new one > repaints. These are totally different bugs, so let's keep them separate. Feel free to file bugs for the other two. 8-bit is "Cairo and XRender just don't support it" 16-bit is the bug we are tracking here. 24-bit is most likely that your X terminal doesn't support the RENDER extension, so apps have to pull images from the server constantly in order to do client-side compositing (indeed, your xdpyinfo doesn't show the RENDER extension). This is going to be horribly slow. xvnc could be a reasonable solution.
All, I'm going to split this into 3 bugs and will do that next week when I return to the office. I'll close out this original bug because it contains information for multiple bugs. Xvnc isn't a good enough fit for us, not enough client platforms, not easy enough for users to configure at their homes, not good enough bandwidth compression. Peter, all of these issues would have to be fixed and working for us to consider SL10/NLD10 for desktops. Everything that we have in place pre-GTK 2.8 is blazingly fast. I have run GTK 2.8 apps on our old thin clients with RENDER missing and it's not anywhere near as slow as it is on Metaframe.
This bug has good info on the issues when running with 16-bit visuals on metaframe. Other bugs should be opened on the 8-bit and 24-bit visuals issues, but please let this one open for 16-bit issues.
Novell logged into our system and recreated and pushed the changes into Cairo and 16bit is working now. Thanks to JPR for the effort. Verified with new RPM from Novell and working. Opening 8 and 24bit issues to track the other problems.