XTS repo - where to?
dbn.lists at gmail.com
Wed Jun 30 06:21:44 PDT 2010
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
> 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).
> 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
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)
#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
More information about the xorg-devel