GNOME Bugzilla – Bug 521371
XRRGetScreenResources error (libXrandr.so.2)
Last modified: 2008-09-18 03:36:08 UTC
Hi, I am having Xerrors running gtk applications with vcs versions of gnome (libs/deps). GNU gdb 6.6-debian Copyright (C) 2006 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) r Starting program: /home/beta/git/gnome2/gtk+/tests/.libs/testgtk [Thread debugging using libthread_db enabled] [New Thread -1222453568 (LWP 9428)] Gdk-ERROR **: The program 'testgtk' received an X Window System error. This probably reflects a bug in the program. The error was 'BadRequest (invalid request code or no such operation)'. (Details: serial 11 error_code 1 request_code 151 minor_code 8) (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.) aborting... Program received signal SIGTRAP, Trace/breakpoint trap.
+ Trace 191863
Thread NaN (LWP 9428)
beta@elmarco-laptop:~/git/gnome2/gtk+/tests$ ldd .libs/testgtk linux-gate.so.1 => (0xffffe000) libgdk_pixbuf-2.0.so.0 => /opt/gnome2/lib/libgdk_pixbuf-2.0.so.0 (0xb7fa7000) libgdk-x11-2.0.so.0 => /opt/gnome2/lib/libgdk-x11-2.0.so.0 (0xb7f02000) libgtk-x11-2.0.so.0 => /opt/gnome2/lib/libgtk-x11-2.0.so.0 (0xb7ab4000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb7a87000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb7a81000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb7a78000) libgio-2.0.so.0 => /opt/gnome2/lib/libgio-2.0.so.0 (0xb7a06000) libpangocairo-1.0.so.0 => /opt/gnome2/lib/libpangocairo-1.0.so.0 (0xb79fc000) libpangoft2-1.0.so.0 => /opt/gnome2/lib/libpangoft2-1.0.so.0 (0xb79c9000) libpango-1.0.so.0 => /opt/gnome2/lib/libpango-1.0.so.0 (0xb7985000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb7982000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb797f000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb797a000) libatk-1.0.so.0 => /opt/gnome2/lib/libatk-1.0.so.0 (0xb795d000) libgobject-2.0.so.0 => /opt/gnome2/lib/libgobject-2.0.so.0 (0xb791e000) libgmodule-2.0.so.0 => /opt/gnome2/lib/libgmodule-2.0.so.0 (0xb791a000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7916000) libglib-2.0.so.0 => /opt/gnome2/lib/libglib-2.0.so.0 (0xb7831000) libselinux.so.1 => /lib/libselinux.so.1 (0xb781b000) libcairo.so.2 => /opt/gnome2/lib/libcairo.so.2 (0xb77a8000) libfontconfig.so.1 => /opt/gnome2/lib/libfontconfig.so.1 (0xb7778000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7708000) libz.so.1 => /usr/lib/libz.so.1 (0xb76f3000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb76d3000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb76b0000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb76a7000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb75b6000) libpixman-1.so.0 => /opt/gnome2/lib/libpixman-1.so.0 (0xb757b000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7556000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb740c000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb7408000) /lib/ld-linux.so.2 (0xb7fc4000) libsepol.so.1 => /lib/libsepol.so.1 (0xb73c7000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb72d4000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb72c9000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb72b0000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb72ab000) ubuntu gutsy: ii xrandr 1:1.2.2-0ubuntu1 X Rotation, Reflection and Resize utility
I just found a launchpad bug reported today: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/199960 I must add that this bug : - appeared about 2/3 weeks ago (I tought it would be fix quickly, or I had a local installation issue and did not report immediatly) - Alex Mayorga Adame pointed out that the bug happen with xorg-driver-fglrx (which I also use) That might well be a driver bug, however, earlier version of gtk did not crash.
Someone else has the pb with 855GM intel driver.
I also enjoy this information coming from valgrind: Gdk-ERROR **: The program 'testgtk' received an X Window System error. This probably reflects a bug in the program. The error was 'BadRequest (invalid request code or no such operation)'. (Details: serial 11 error_code 1 request_code 151 minor_code 8) (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.) aborting... vex x86->IR: unhandled instruction bytes: 0xCC 0xEB 0x5 0xE8 ==21789== valgrind: Unrecognised instruction at address 0x471A2D3. ==21789== Your program just tried to execute an instruction that Valgrind ==21789== did not recognise. There are two possible reasons for this. ==21789== 1. Your program has a bug and erroneously jumped to a non-code ==21789== location. If you are running Memcheck and you just saw a ==21789== warning about a bad jump, it's probably your program's fault. ==21789== 2. The instruction is legitimate but Valgrind doesn't handle it, ==21789== i.e. it's Valgrind's fault. If you think this is the case or ==21789== you are not sure, please let us know and we'll try to fix it. ==21789== Either way, Valgrind will now raise a SIGILL signal which will ==21789== probably kill your program. ==21789== ==21789== Process terminating with default action of signal 4 (SIGILL)
beta@elmarco-laptop:~/git/gnome2/gtk+$ xrandr X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 151 (RANDR) Minor opcode of failed request: 6 () Serial number of failed request: 9 Current serial number in output stream: 9 beta@elmarco-laptop:~/git/gnome2/gtk+$ xdpyinfo name of display: localhost:10.0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 70000000 X.Org version: 7.0.0 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 4, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x3c007f0, revert to Parent number of extensions: 28 BIG-REQUESTS Composite DAMAGE DEC-XTRAP DOUBLE-BUFFER DPMS Extended-Visual-Information GLX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RANDR RECORD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP X-Resource XC-APPGROUP XC-MISC XFIXES XFree86-Bigfont XInputExtension XKEYBOARD XTEST XVideo default screen number: 0 number of screens: 1 screen #0: dimensions: 1400x1050 pixels (289x210 millimeters) resolution: 123x127 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 root window id: 0x52 depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store NO, save-unders NO largest cursor: 1400x1050 current input event mask: 0x7a803f KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask ExposureMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask number of visuals: 4 default visual id: 0x2c visual: visual id: 0x2c class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2d class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2e class: TrueColor depth: 32 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2f class: TrueColor depth: 32 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits
Created attachment 106909 [details] xorg.log xorg.log
Seems your driver does not support XRANDR 1.2, yet GDK is doind 1.2 specific requests. Seems there is a version check missing somewhere.
Strangely, if I run a second X manually, with startx -- :2, then xrandr does not fail... and gtk does not fail neither..
(In reply to comment #7) > Strangely, if I run a second X manually, with startx -- :2, then xrandr does > not fail... and gtk does not fail neither.. > could it be a X versus Xgl difference?
GTK+ has this code in gdkscreen-x11.c that should prevent it from sending RandR 1.2 requests to a non-RandR 1.2 server: if (!display_x11->have_randr12) return FALSE; This gets initialized in gdkdisplay-x11.c: /* RandR must be initialized before we initialize the screens */ display_x11->have_randr12 = FALSE; #ifdef HAVE_RANDR if (XRRQueryExtension (display_x11->xdisplay, &display_x11->xrandr_event_base, &ignore)) { int major, minor; XRRQueryVersion (display_x11->xdisplay, &major, &minor); if ((major == 1 && minor >= 2) || major > 1) display_x11->have_randr12 = TRUE; } #endif which looks correct enough to me. Someone who can reproduce would have to debug this. If this is a server issue, we may have to do some workaround like using gdk_error_trap_push/pop around the first XRRGetScreenResources or something.
Created attachment 118870 [details] [review] workaround patch
I created a patch based on Soren's suggestion. This is just a workaround, I cannot figure out the real reason yet. I can reproduce the problem when remote login from a X86 box to a Sparc box(with Xsun and no XrandR), I cannot open any application. I doubt there is some protocol miscommunication. However, as someone else also met the same problem, and it kinda hard to identify the real reason without involving X expert. I suggested to use this patch for the time being
This bug is obsolete, since we are not calling XRRGetScreenResources anymore.
Will the fix reflect on 2.14 branch or only on trunk?