bump: Xorg segfaults on XOpenDisplay multi thread

[Matan Drori]

hi bill
i went to that direction, i linked to libpthread didn't do any good
i tried working with ptmalloc3 instead of the ptmalloc2 thats in glibc,
and it didn't do any good so i went back one layer up to the Xorg
I did that since i couldn't re produce bug by linking malloc debuggers
to my programs(tried dmalloc and Electric fence)
but it seems like it doesn't reproduce just cause the malloc debugger
has different timings.

i agree that the  ciptr=0x0 is very suspicious, after looking further
into it (Xorg debug without -o2) i saw that it goes a bit up.
looks like there is no connection with the server, or maybe its just a
memory override somewhere along the way.
couldn't quite pin point the spot.
and it couldn't be that the dpy->trans_conn got a wrong value when
connected because if so the it would have returned null after the call
for _X11TransConnectDisplay
*OpenDis.c:154*
 if ((dpy->trans_conn = _X11TransConnectDisplay (
                                         display_name, &fullname, &idisplay,
                                         &iscreen, &conn_auth_name,
                                         &conn_auth_namelen,
&conn_auth_data,
                                         &conn_auth_datalen)) == NULL) {
                Xfree ((char *) dpy);
                return(NULL);
}
(dpy->trans_conn is what we later send as the ciptr...)
I also added a print for all the data sent in this function and it
always prints the correct information, even when sagfaults.

if you look at the second segfualt its in a very simple line
*OpenDis.c:262*
if ((dpy->bufptr = dpy->buffer = Xcalloc(1, conn_buf_size)) == NULL)
just a simple calloc(buffer size correct, always), and that really
puzzled me... but i guess its just something corrupted in the memory.

any thing else you think might lead this?

Bill Crawford wrote:
> On Sunday 28 December 2008 08:56:50 Matan Drori wrote:
>   
>> Bump, adding some backtraces:
>> Dump 1:
>> #0  _X11TransWritev (ciptr=0x0, buf=0x2000000001b96720, size=1) at
>> ../../lib/xtrans/Xtrans.c:911
>> #1  0x2000000000093910 in _XSendClientPrefix (dpy=<value optimized out>,
>> client=<value optimized out>, auth_proto=0x0, auth_string=0x0,
>> prefix=0x2000000001b96784) at ConnDis.c:572
>> #2  0x20000000000c4640 in XOpenDisplay (display=<value optimized out>)
>> at OpenDis.c:295
>> #3  0x4000000000001580 in ThreadMain_OpenDisplayAndStartTest (num=0x1)
>> at ../../thread.cpp:37
>> #4  0x200000000027d5d0 in start_thread () from /lib/libpthread.so.0
>> #5  0x20000000007cb730 in __clone2 () from /lib/libc.so.6.1
>> Dump 2:
>> #0  0x200000000070f350 in malloc_consolidate () from /lib/libc.so.6.1
>> #1  0x2000000000714830 in _int_malloc () from /lib/libc.so.6.1
>> #2  0x2000000000716ef0 in calloc () from /lib/libc.so.6.1
>> #3  0x20000000000c4530 in XOpenDisplay (display=<value optimized out>)
>> at OpenDis.c:262
>> #4  0x4000000000001580 in ThreadMain_OpenDisplayAndStartTest (num=0x2)
>> at ../../thread.cpp:37
>> #5  0x200000000027d050 in start_thread () from /lib/libpthread.so.0
>> #6  0x20000000007cb730 in __clone2 () from /lib/libc.so.6.1
>>
>> i explored this topic for quite a while, when i debug it i see memory
>> corruptions every time it crashes. memory corruptions doesn't always occur
>> at the same place which makes it even harder and more confusing.
>>     
>
> Well, the ciptr=0x0 looks suspicious, to say the least. But it smells like you 
> have an issue with thread safety somewhere underneath libX11, like in the C 
> library. Did you link against libpthread?
>