[xcb] Unknown request in queue while dequeuing

[neagix]

Hi guys,

I am using SFML 2.0 and DSFML from git and since my last system upgrade (Arch Linux here) of xcb-proto (1.10-1 -> 1.10-2) I receive this error:

[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
superkeen: xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.


I cannot say the specific upgrade of xcb-proto is responsible for this issue, but I'd rather say there is something fishy going on on the SFML libraries side.

Has somebody else experienced it? Does using SFML 2.1 solve this? I have not tried SFML 2.1 because I do not know if it will work with current DSFML

Edit: more information (gdb stacktrace, no symbols for SFML sorry):

Code: [Select]

#0  0x00007ffff54af389 in raise () from /usr/lib/libc.so.6
No symbol table info available.
#1  0x00007ffff54b0788 in abort () from /usr/lib/libc.so.6
No symbol table info available.
#2  0x00007ffff54a84a6 in __assert_fail_base () from /usr/lib/libc.so.6
No symbol table info available.
#3  0x00007ffff54a8552 in __assert_fail () from /usr/lib/libc.so.6
No symbol table info available.
#4  0x00007ffff619240c in ?? () from /usr/lib/libX11.so.6
No symbol table info available.
#5  0x00007ffff619324b in _XReply () from /usr/lib/libX11.so.6
No symbol table info available.
#6  0x00007ffff617e8df in XInternAtom () from /usr/lib/libX11.so.6
No symbol table info available.
#7  0x00007ffff3be7c80 in ?? () from /usr/lib/libsfml-window.so.2
No symbol table info available.
#8  0x00007ffff3be814d in ?? () from /usr/lib/libsfml-window.so.2
No symbol table info available.
#9  0x00007ffff3be2cb3 in ?? () from /usr/lib/libsfml-window.so.2
No symbol table info available.
#10 0x00007ffff3be2a15 in sf::Window::create(sf::VideoMode, sf::String const&, unsigned int, sf::ContextSettings const&) ()
   from /usr/lib/libsfml-window.so.2
No symbol table info available.
#11 0x00007ffff730a21c in sfRenderWindow_create () from ~/DSFML-C/build/lib/libdsfml-graphics.so.2
No symbol table info available.
#12 0x000000000054279d in dsfml.graphics.renderwindow.RenderWindow.__ctor() (this=0x7ffff7eb1d40,
    settings=0x7d24e0 <dsfml.window.contextsettings.ContextSettings.Default()>, style=<incomplete type>, title=..., mode=...)
    at ~/.dub/packages/dsfml-master/src/dsfml/graphics/renderwindow.d:76
No locals.
#13 0x00000000004e6b9c in D main (args=...)
    at ~/.dub/packages/dsfml-master/src/dsfml/graphics/renderwindow.d:73
        config = 0x7ffff7eb1e40
        __ctmp2343 = {width = 800, height = 600, bitsPerPixel = 32}
        mainMenu = 0x0
        delta = 8451312
#14 0x000000000055906c in rt.dmain2._d_run_main() ()
No symbol table info available.
#15 0x0000000000558fc6 in rt.dmain2._d_run_main() ()
No symbol table info available.
---Type <return> to continue, or q <return> to quit---
#16 0x000000000055902c in rt.dmain2._d_run_main() ()
No symbol table info available.
#17 0x0000000000558fc6 in rt.dmain2._d_run_main() ()
No symbol table info available.
#18 0x0000000000558f47 in _d_run_main ()
No symbol table info available.
#19 0x00000000004ecc05 in main ()
No symbol table info available.
#20 0x00007ffff549bb05 in __libc_start_main () from /usr/lib/libc.so.6
No symbol table info available.
#21 0x00000000004e6599 in _start ()
No symbol table info available.

It seems like the culprit it's a call to XInternAtom() from libsfml-window. I think xcb does not allow anymore to call this from different threads. This might be due to the way DSFML is first creating the surfaces and then using them (different threads?)

[Jebbs]

Not sure why it would happen after you upgraded, but I don't think this is DSFML's fault. Doing some searches, people have gotten the same errors using regular SFML, but I will need more information about what exactly you are trying to do in order to point you in the right direction. You could just see if calling XInitThreads fixes the problem, or provide a minimal example that reproduces the issue if you're still having issues.

[neagix]

I also did my googling before, the fact it happens on regular SFML (tip: check the threads date) means little or nothing because different bugs can lead to this same outcome, the stacktrace identifies better if it's the same bug or not.

Question here is: is DSFML accessing xlib-allocated resources from different threads?

If yes, then it can be DSFML fault.

[neagix]

Hey Jebbs, I am building a minimal testcase since doesn't happen through an application that just opens a window without doing anything else. Once I finish it will be easier to pinpoint the root cause; meanwhile would be nice to hear about the possibility of accessing the graphics resources from different threads as per my question above. I will also check if the thread issue has roots in my code for some reason

[neagix]

Wow, this is a tough one to digest. I think I found the reason.

If I do some initialization in the static constructor of a D class, then I get this error. If I do the same initialization explicitly from the main of the program, everything is fine and cool. How evil is that? 

I guess it's not even DSFML here the culprit, but D that is using a different thread for the static constructor than the thread for main, and XCB is keeping track of this.

So it was definitively not the xcb update that gave me this problem, but me moving initialization into a static constructor!

Thanks for the support, can you shed some further light on what I found out? It might be worth putting a disclaimer somewhere - or it might just be me that I didn't know this was a regular D behaviour (is it?)

[Jebbs]

Well, if you did get a minimal example, I would love to see it and maybe mess around with it.

If static constructors are run in a different thread, that is something I wasn't aware of at all. I guess it kind of makes sense, but still seems a little strange. A disclaimer is definitely something easily done and probably should be done.

Did you ever try to call XInitThreads to see if that fixes it? If things are happening like I am imagining them happening it probably won't work, but it might be worth trying out.

[neagix]

Sorry for the late reply, as requested I provided a testcase here:
https://github.com/Jebbs/DSFML/issues/106

it is interesting to see that it is only verifiable when using std.concurrency; but I guess discussion shall continue on the github issue tracker now

[Jebbs]

Awesome. I'll check it out and will try to get back to you before Monday.

This only happens on Linux, right? Have you tried it on Windows or maybe OSX at all?

[neagix]

Awesome. I'll check it out and will try to get back to you before Monday.

This only happens on Linux, right? Have you tried it on Windows or maybe OSX at all?

I checked only on Linux, but xcb is an extension of X11 and there are also other important differences (threading) so if it would be happening also on Windows, the error would be certainly different. I doubt it can give problems there, but it's possible on OSX (however I do not have any Mac to try with).

[Gaer]

Has this been resolved somehow / did you figure out what's going on?

I have a similar looking problem and couldn't find anything more recent than this thread regarding the topic...

[Jebbs]

I was able to make it work by calling XInitThreads before anything else was called, although neagix never confirmed that it had worked for them. SFML merged the xcb branch not long ago, so when I start working on the 2.3 release this will be completely resolved. Until then, I'm going to add a method to the thread class that will expose XInitThreads on Linux.

I'm gearing up the release of 2.1, so that method will appear in the master branch pretty soon.