[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