[Pkg-fglrx-devel] Bug#735047: [Xcb] Bug#735047: fglrx-driver: openGL applications segfaults on igpu configuration

[Uli Schlachter]

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 at 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 at entry=0x608010, opcode=<optimized out>,
screen=screen at entry=0, name=name at 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