[Xcb] xlibs --with-xcb unbroken

[Bernardo Innocenti]

Jamey Sharp wrote:
> On Sat, Feb 12, 2005 at 10:21:42AM +0100, Bernardo Innocenti wrote:
> 
>>Bernardo Innocenti wrote:
>>
>>>Bernardo Innocenti wrote:
>>>
>>>>I still can't run xclock from the xorg tree with an XCB-enabled
>>>>libX11.  xterm works fine.
>>>>
>>>>Looks like a problem in getting the font list from the server:
>>>
>>>More specifically, X response for the query of 
>>>"-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-1"
>>>appears to contain something before the usual reply that XCB does not like
>>>(see the last read()).
>>
>>Newsflash: looks like a buffer overrun bug to me.
>>In _xcb_in_read_packet(), _xcb_list_find() returns an
>>XCBReplyData struct containing garbage from some
>>previous read() call:
>>
>>$39 = {
>> cond = {
>>   __c_lock = {
>>     __status = 134628032,
>>     __spinlock = 1768303993
>>   },
>>   __c_waiting = 0x2d646578,
>>   __padding = "medium-r-normal--16-120-100-",
>>   __align = 3474577016499482673
>> },
>> pending = 1,
>> error = 0,
>> request = 38,
>> data = 0x0
>>}
> 
> 
> Those *are* malloc'ed structures. I wouldn't be at all shocked if the
> condition variables frequently have results from previous read()s in
> their padding bytes.

You're right for the padding stuff, but the lock isn't
actually initialized.

I've gone back to the place where that XCBReplyData structure
is allocated, and it's corrupted right from the start, even
tough there's actually a call to pthread_cond_init().

It seems pthread_cond_init() is a no-op.  I wrote a one-liner
test and it works the same, until I build with -pthread.

I didn't know: glibc exports a dummy pthread_cond_init
weak symbol that gets overridden by libpthread.

That's silly, it means that even if you build single-threaded
programs, your code still jumps into pthread stubs -> almost
the same overhead.  I think they had to do that to allow
mixing code built with and without threading support.


> ListFontsWithInfo generates one X reply for every font on the system. I
> would expect that you'd see a result like the above for the first of
> those replies (and that would work fine), but the subsequent replies
> would lose. Is that different from what you're seeing?

Yes, the second time, rep->data still points to old data
and the assertion fails.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/