[Xcb] xcb recursive write not protected in all cases?

Uli Schlachter psychon at znc.in
Tue Dec 24 07:17:01 PST 2013

Hi again,

On 24.12.2013 02:00, Keith Packard wrote:
> I'm reading a backtrace provided by an Intel business partner and found
> the following:
>    #0  0xf73b81c5 in raise () from /lib/i386-linux-gnu/libc.so.6
>    #1  0xf73bb663 in abort () from /lib/i386-linux-gnu/libc.so.6
>    #2  0xf73b10c7 in ?? () from /lib/i386-linux-gnu/libc.so.6
>    #3  0xf73b1177 in __assert_fail () from /lib/i386-linux-gnu/libc.so.6
>    #4  0xf779992d in write_vec (count=0xb8ab49f8, vector=0xb8ab49f4, 
>    c=0xc309ce0)
> 	at ../../src/xcb_conn.c:180
>    #5  _xcb_conn_wait (c=c at entry=0xc309ce0, cond=cond at entry=0xc30ad74,
> 	vector=vector at entry=0xb8ab49f4, count=count at entry=0xb8ab49f8)
> 	at ../../src/xcb_conn.c:443
>    #6  0xf7799d38 in _xcb_out_send (c=c at entry=0xc309ce0,
> 	vector=vector at entry=0xb8ab4a18, count=count at entry=1)
> 	at ../../src/xcb_out.c:345
>    #7  0xf779a650 in _xcb_out_flush_to (c=0xc309ce0, request=18557)
> 	at ../../src/xcb_out.c:372
>    #8  0xf779a758 in xcb_take_socket (c=0xc309ce0,
> 	return_socket=0xf7693120 <return_socket>, closure=0xc339090, flags=0,
> 	sent=0xb8ab4ab8) at ../../src/xcb_out.c:271
>    #9  0xf76929e6 in require_socket (dpy=0xc339090) at ../../src/xcb_io.c:67
>    #10 0xf769348f in require_socket (dpy=0xc339090) at ../../src/xcb_io.c:59
>    #11 _XFlush (dpy=0xc339090) at ../../src/xcb_io.c:510

Attached is a small test program which seems to hit the same bug (same
backtrace), but does not involve Xlib.

This starts two threads. The main thread just calls xcb_no_operation() in a loop
while the other thread calls xcb_take_socket() and xcb_no_operation() in a loop.
Thus, the main thread can put a NoOp request in the output buffer while
xcb_take_socket() flushes the NoOp request that came from the same thread, as
already explained by Keith:

> So, if some other thread gets between the assignment setting queue_len
> to 0 and the eventual write_vec call, it will end up smashing data over
> the top of out.queue. We can tell that happened because queue_len will
> be non-zero again.

Just wanted to post this so that there is a test case in the mailing list
archives (I wanted to hit another bug instead).

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.c
Type: text/x-csrc
Size: 744 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20131224/4884cdc2/attachment.c>

More information about the Xcb mailing list