[Xcb] X Test Suite: not my fault, part 14,263

[Barton C Massey]

Is not the right thing to fix these XTS bugs as we find
them, and submit the patches back to fd.o/x.org?  Most of
them seem not-too-hard to fix...

BTW, I thought you diagnosed this one long ago?  Or is this
another instance of the same problem?  Excellent work, in
any case!

	Bart

In message <20050401091934.GI21042 at minilop.net> you wrote:
> I've tracked down one of the more frustrating assertion failures in the
> X Test Suite, and it's another case of "not my fault": the test is just
> busted. It only works with standard Xlib because standard Xlib doesn't
> check for this particular error, and survives it long enough to complete
> the test.
> 
> CH02/clsdsply, IC 6, opens two connections to the X server, issues a
> handful of requests on each, then forks. The first connection is
> subsequently used only in the parent, but the second... The child issues
> a request on the 'client2' connection and exits, and then the parent
> checks to see whether the 'client2' connection recieved a particular
> event. The event's sequence number is enough to tell Xlib/XCB that some
> other process made some requests on the same connection, which triggers
> the assertion.
> 
> It seems completely insane to expect a Display structure to be usable in
> both processes after a fork, but some tests do. I'm inclined to say that
> these test should be ignored for the purposes of testing Xlib/XCB, just
> as I'm ignoring all the XPROTO tests (because they don't use LockDisplay
> and UnlockDisplay, which is also just wrong).
> 
> Ch02/clsdsply, IC 8, also dies in an assert, but as it doesn't fork I
> guess the bug is different. Also, the various Xlib-based apps I use
> still die occasionally, so I guess *something* is up.
> 
> --Jamey
> _______________________________________________
> xcb mailing list
> xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb