After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 521371 - XRRGetScreenResources error (libXrandr.so.2)
XRRGetScreenResources error (libXrandr.so.2)
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: X11
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2008-03-09 13:41 UTC by Marc-Andre Lureau
Modified: 2008-09-18 03:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
xorg.log (40.58 KB, text/plain)
2008-03-09 15:14 UTC, Marc-Andre Lureau
  Details
workaround patch (477 bytes, patch)
2008-09-17 11:26 UTC, Chris Wang
none Details | Review

Description Marc-Andre Lureau 2008-03-09 13:41:25 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.

Thread NaN (LWP 9428)

  • #0 IA__g_logv
    at gmessages.c line 493
  • #1 IA__g_log
    at gmessages.c line 517
  • #2 gdk_x_error
    at gdkmain-x11.c line 641
  • #3 _XError
    from /usr/lib/libX11.so.6
  • #4 _XReply
    from /usr/lib/libX11.so.6
  • #5 XRRGetScreenResources
    from /usr/lib/libXrandr.so.2
  • #6 init_randr12
    at gdkscreen-x11.c line 681
  • #7 init_multihead
    at gdkscreen-x11.c line 861
  • #8 _gdk_x11_screen_new
    at gdkscreen-x11.c line 905
  • #9 IA__gdk_display_open
    at gdkdisplay-x11.c line 190
  • #10 IA__gdk_display_open_default_libgtk_only
    at gdk.c line 288
  • #11 IA__gtk_init_check
    at gtkmain.c line 915
  • #12 IA__gtk_init
    at gtkmain.c line 950
  • #13 main
    at testgtk.c line 13745


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
Comment 1 Marc-Andre Lureau 2008-03-09 13:54:11 UTC
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.
Comment 2 Marc-Andre Lureau 2008-03-09 14:01:27 UTC
Someone else has the pb with 855GM intel driver.
Comment 3 Marc-Andre Lureau 2008-03-09 14:10:04 UTC
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)
Comment 4 Marc-Andre Lureau 2008-03-09 15:12:05 UTC
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
Comment 5 Marc-Andre Lureau 2008-03-09 15:14:20 UTC
Created attachment 106909 [details]
xorg.log

xorg.log
Comment 6 Johan Bilien 2008-03-09 15:21:06 UTC
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.
Comment 7 Marc-Andre Lureau 2008-03-09 15:49:17 UTC
Strangely, if I run a second X manually, with startx -- :2, then xrandr does not fail... and gtk does not fail neither.. 
Comment 8 Marc-Andre Lureau 2008-03-09 15:52:22 UTC
(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? 
Comment 9 Soren Sandmann Pedersen 2008-03-12 06:14:44 UTC
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.
Comment 10 Chris Wang 2008-09-17 11:26:25 UTC
Created attachment 118870 [details] [review]
workaround patch
Comment 11 Chris Wang 2008-09-17 11:31:17 UTC
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
Comment 12 Matthias Clasen 2008-09-17 15:20:16 UTC
This bug is obsolete, since we are not calling XRRGetScreenResources anymore.
Comment 13 Chris Wang 2008-09-18 03:36:08 UTC
Will the fix reflect on 2.14 branch or only on trunk?