In the attached sample, using Xlib with XCB (FC8) the application exists. With a regular X lib it works fine. Looks like the error is not delivered to the right thread.
Created attachment 18159 [details] testcase
Looks like this happens with all syncrounos X APIs, such as XSync and XGrabPointer.
As written, the test code will open the display before XInitThreads is called. Try creating the xDisplay object explicitly in main() after XInitThreads.
Tried it. Didn't work. Thanks.
Created attachment 30228 [details] Simplified test case. I've reduced the original test case to pure C to ensure that C++ initializer ordering isn't screwing up the test, but I get an immediate exit whether the event thread runs or not. I guess I don't understand the problem.
Would you explain more clearly what you expected to happen when you run your test program? The extra thread has no effect on its behavior for me. Perhaps you could propose a different test program that doesn't involve colormaps?
Created attachment 30270 [details] Locked simplified test I have added some pthread locking that allows the secondary thread to start and get to XNextEvent before the main thread starts with its test. Instead of resulting in "failed when npixels == 54" (first step in the loop), it exits with: "XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "<machine>:0.0" after 7 requests (6 known processed) with 0 events remaining." If still needed, I can test with some other syncronous API that may process protocol errors.
I have made some modification to the libX11 - XCB integration that resolved this issue. Would love to get some review for these changes. I am attaching the suggested solution. Yaakov
Created attachment 32679 [details] Suggested fix, part I
Created attachment 32680 [details] Suggested solution, part II
> --- Comment #8 from ykaston <ykaston@gmail.com> 2010-01-17 07:36:21 PST --- > I have made some modification to the libX11 - XCB integration that resolved > this issue. > Would love to get some review for these changes. > > I am attaching the suggested solution. > it's easier to review your changes if you attach a patch against the current tree rather than complete files where it's impossible to tell what you changed.
Created attachment 32685 [details] [review] Patch for suggested solution As requested, a patch file...
Your patch header suggests that you worked from libX11 1.2. To make it easier for us to review, can you please verify that the bug in question still exists with current libX11 (1.3.3), and that your patch still applies there? Thank you.
I did make the fix on top of 1.2. And the bug is still there in 1.3.3.
The bug is still there in 1.4.0
As mentioned above, the patches to fix this were based on an old libX11. Please provide an updated patch based on libX11 master (or at least 1.4.x) so that it can have some hope of applying.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.