Hi, On 02.02.2014 17:41, Julien Cristau wrote: [...] >> On 2014-02-01 23:18, Alexander V. Kudrevatykh wrote: >>> В Чтв, 30/01/2014 в 01:05 +0100, Andreas Beckmann пишет: >>>> First step of debugging would be to run glxinfo inside gdb and get a >>>> backtrace >>>> after the crash. And maybe running it under strace, too. >> >>> In attachment you can find gdb and strace output for glxinfo >> >>> Program received signal SIGSEGV, Segmentation fault. >>> xcb_glx_query_server_string_string_length (R=R@entry=0x0) at glx.c:2460 >> >> Null-pointer dereference in libxcb-glx0. >> >> The caller seems to be >> http://sources.debian.net/src/mesa/9.2.2-1/src/glx/glx_query.c?hl=55#L55 >> (but this is code from sid, codesearch.d.n does not have wheezy) >> >> Reassigning to libxcb since I don't know how to debug further.
There is no bug in xcb-glx here. Mesa doesn't do the necessary error checking for this request (as evident by the reply = 0x0 in gdb output). The GLX QueryServerString request failed, the error for this was ignored (NULL argument to xcb_glx_query_server_string_reply()) and the caller then tried to extract data from the NULL pointer reply. >From the strace output, the last request sent is this one: writev(3, [{"\232\23\3\0\0\0\0\0\2\0\0\0", 12}], 1) = 12 This is a request with length 3*4=12 (third and fourth byte, little endian), major number 0232 = 154 and minor number 023 = 19. Major numbers are assigned dynamically, thus no idea what the 154 means (but xdpyinfo -ext all | grep "opcode: 154" would tell us), but the minor number 19 could help. GLX QueryServerString has minor 19, which would mean the request contains screen=0 and name=2 which maches the output from gdb __glXQueryServerString (dpy=dpy@entry=0x608010, opcode=<optimized out>, screen=screen@entry=0, name=name@entry=2) (Also I just looked up the GLX QueryExtension request from the strace output and 0232 is indeed GLX...) The reply to this seems to be: recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"\0\1\17\0\27\0\0\0\23\0\232\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 32 This is an error (\0) with error code 1 and sequence number 15 (\17\0). The fields are: resource_id = \27\0\0\0 = 23, minor_code = \23\0 = 19, major_code = \232 = 154 and all following fields being zero. Error code 1 is a request error. From Xlib's src/XErrorDB this is described as "BadRequest (invalid request code or no such operation)". Some other docs[1] say "The major or minor opcode does not specify a valid request.". I am confused... TL;DR: No bug in anything xcb-related here, but there is (a) a bug in mesa where it doesn't handle a request failure correctly and (b) some weirdness that I don't understand that makes the server claim to support GLX, but not support GLX QueryServerString. Cheers, Uli [0]: http://cgit.freedesktop.org/xorg/xserver/tree/glx/glxcmds.c#n2390 [1]: http://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.html#errors -- 99 little bugs in the code 99 little bugs in the code Take one down, patch it around 117 little bugs in the code -- @irqed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org