XTS repo - where to?

[Dan Nicholson]

On Tue, Jun 29, 2010 at 11:14 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> Adding xcb list, I _think_ this is an xcb issue.
>
> On Tue, Jun 29, 2010 at 05:39:41AM -0700, Dan Nicholson wrote:
>> On Tue, Jun 29, 2010 at 4:07 AM, Daniel Stone <daniel at fooishbar.org> wrote:
>> > On Tue, Jun 29, 2010 at 04:11:04PM +1000, Peter Hutterer wrote:
>> >> XTS still lives in dan's, aaron's and my $HOME on annarchy.  Which is not
>> >> ideal, for obvious reasons. We've had this discussion on IRC a few times,
>> >> with my current preferences being either
>> >>     /git/xorg/xts
>> >> or
>> >>     /git/xorg/tests/xts
>> >>
>> >> The second optimistically thinking that over time we may accumulate more
>> >> tests that need to go in there. Do we have any, or in the near future will
>> >> we see any? If not, then I'd opt for the first one.
>> >
>> > I've set up /git/xorg/test/xts, per Tiago & Mikhail's comments, and
>> > noting that the other dirs are called lib instead of libs, app instead
>> > of apps, et al.
>> >
>> > Cheers,
>> > Daniel
>> >
>> > PS: You own XTS.  Ha!
>>
>> Peter, I've got your branch you sent me plus a bunch of local fixes. I
>> just pushed it to ~dbn/xts.git master.
>>
>> One thing that happened is that your DISPLAY fixes corrected a bug
>> where tests forking themselves now properly try to open the correct
>> display instead of bailing out because DISPLAY isn't set. This was
>> making Xlib3/XConnectionNumber hang in XFlush on me yesterday. Can you
>> have a look at that one? I can't figure out what would make that
>> happen.
>
> Looks like this may be some rather weird behaviour xcb doesn't cater for.
>
> closer() in xts5/Xlib3/XConnectionNumber.c calls close(2) on the display's
> fd. Then it calls XFlush(3).
> http://cgit.freedesktop.org/xorg/test/xts/tree/xts5/Xlib3/XConnectionNumber.m#n128
>
> XFlush(3) eventually calls _xcb_out_send() with has the following loop:
>    while(ret && *count)
>            ret = _xcb_conn_wait(c, &c->out.cond, vector, count);
>
> _xcb_conn_wait(), if built with USE_POLL gets the POLLNVAL error. It only
> checks for POLLIN and POLLOUT though, ignoring the error.
> Return value is 1, count is unmodified, leaving us with an endless loop and
> the hang you noticed.
>
> Now you could argue that closing the file descriptor on xcb is nasty but I
> think xcb should probably cater for this eventuality. Am I reading this
> right?

Seems like a solid analysis to me. Here's a backtrace ending at closer().

#0  0x000000329e2d5318 in poll () from /lib64/libc.so.6
#1  0x00007f6ee7da686a in _xcb_conn_wait (c=0xe6ca00,
    cond=<value optimized out>, vector=0x7fffd2d981e8, count=0x7fffd2d981e4)
    at xcb_conn.c:306
#2  0x00007f6ee7da6df7 in _xcb_out_send (c=0xe6ca00, vector=0x7fffd2d981e8,
    count=0x7fffd2d981e4) at xcb_out.c:338
#3  0x00007f6ee7da70a5 in xcb_writev (c=0xe6ca00, vector=0x7fffd2d98240,
    count=3, requests=1) at xcb_out.c:286
#4  0x00007f6ee8006d9a in _XSend (dpy=0xe6b7b0, data=<value optimized out>,
    size=<value optimized out>) at xcb_io.c:339
#5  0x00007f6ee80072d5 in _XFlush (dpy=0xe6b7b0) at xcb_io.c:356
#6  0x00007f6ee7fdef0a in XFlush (dpy=0xe6b7b0) at Flush.c:39
#7  0x000000000040257f in closer () at XConnectionNumber.c:171

--
Dan