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

[Uli Schlachter]

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).

Uli
-- 
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>