[Xcb] xlibs --with-xcb unbroken

Jamey Sharp jamey at minilop.net
Sat Feb 12 01:28:54 PST 2005


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.

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?

--Jamey


More information about the xcb mailing list