SMFL Draw Causing Crash, SFML 2.4

[tyjo99]

I am trying to make a GUI for a program that has a CUDA accelerated back end which runs on a remote server. I currently am trying to compiling with nvcc only instead of nvcc and g++. I am viewing the GUI using X11 forwarding to a windows machine, and I know X11 forwarding is not the main issue since I can run other X11 programs like xeyes.

Server OS: Ubuntu 18.04 LTS
SFML version: 2.4

I am currently encountering a issue which causes any SFML program installed on this machine to crash with a nearly identical stack trace, though the stack trace doesn't automatically print out. The error printed to the command line is "XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server "localhost:11.0" after 142 requests (142 known processed) with 8 events remaining."

Stack trace generated using GNU backtrace from atexit()

./a.out(+0x887b) [0x55a5ae59b87b]
/lib/x86_64-linux-gnu/libc.so.6(+0x43161) [0x7feac689c161]
/lib/x86_64-linux-gnu/libc.so.6(+0x4325a) [0x7feac689c25a]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XDefaultIOError+0x85) [0x7feac5da5835]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XIOError+0x4e) [0x7feac5da5a5e]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XReply+0x491) [0x7feac5da3b41]
/usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0(+0x84e16) [0x7feac3eafe16]
/usr/lib/x86_64-linux-gnu/libsfml-graphics.so.2.4(+0x12bb2) [0x7feac7ff1bb2]
/usr/lib/x86_64-linux-gnu/libsfml-graphics.so.2.4(_ZN2sf12RenderTarget14applyBlendModeERKNS_9BlendModeE+0x7f) [0x7feac800696f]
/usr/lib/x86_64-linux-gnu/libsfml-graphics.so.2.4(_ZN2sf12RenderTarget13resetGLStatesEv+0x1f8) [0x7feac8007038]
/usr/lib/x86_64-linux-gnu/libsfml-graphics.so.2.4(_ZN2sf12RenderTarget4drawEPKNS_6VertexEmNS_13PrimitiveTypeERKNS_12RenderStatesE+0x238) [0x7feac80074d8]
/usr/lib/x86_64-linux-gnu/libsfml-graphics.so.2.4(_ZNK2sf11VertexArray4drawERNS_12RenderTargetENS_12RenderStatesE+0x3c) [0x7feac801461c]
/usr/lib/x86_64-linux-gnu/libsfml-graphics.so.2.4(_ZN2sf12RenderTarget4drawERKNS_8DrawableERKNS_12RenderStatesE+0x39) [0x7feac80065a9]
/usr/lib/x86_64-linux-gnu/libsfml-graphics.so.2.4(_ZNK2sf5Shape4drawERNS_12RenderTargetENS_12RenderStatesE+0x42) [0x7feac8011362]
/usr/lib/x86_64-linux-gnu/libsfml-graphics.so.2.4(_ZN2sf12RenderTarget4drawERKNS_8DrawableERKNS_12RenderStatesE+0x39) [0x7feac80065a9]
./a.out(+0x9064) [0x55a5ae59c064]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7feac687abf7]
./a.out(+0x868a) [0x55a5ae59b68a]
 

This occurs for simple programs like the following, even if they are compiled using g++

    // Create the main window
    sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");
    // Load a sprite to display
    sf::CircleShape shape(50);

    // set the shape color to green
    shape.setFillColor(sf::Color(100, 250, 50))
    ;
    while (window.isOpen())
    {
        // Process events
        sf::Event event;
        while (window.pollEvent(event))
        {
            // Close window: exit
            if (event.type == sf::Event::Closed)
                window.close();
        }
        // Clear screen
        window.clear();
        // Draw the sprite
        window.draw(shape);
        // Update the window
        window.display();
    }

These crashes occur in the draw step since if the draw is commented out, they do not occur.

[tyjo99]

Am I asking this in the wrong place? Or do you need any more details?

[eXpl0it3r]

You're on an outdated version of SFML, doing relatively esoteric things with nvcc and a remote server with X11 forwarding. There are so many places where something could go wrong and nobody will really be able to reproduce this issue.

Doing a web search for "fatal IO error 11 (Resource temporarily unavailable) on X server" reveals a lot of topics, with various configuration hints.

First and for most, I'd try updating to SFML 2.5.1 or even better to the yet unreleased 2.6.x branch.
That way you will get all the latest changes and fixes to the X11 code.

Next step would then be to try and isolate the issue further. If you run it locally, does the error still occur.
If not, then you know it's probably something with the X11 forwarding.
Then to make things easier, you could try and see (if that's even possible) whether running a local X server + forwarding still causes the issue.

If it's indeed some X11 forwarding issue, then I'd try to find a tool with which I can track/visualize the X protocol in action and hope to see what exactly is going wrong in there.
As I'm not familiar how that works, I can't really give you much more tips.

[tyjo99]

Thanks for the tips. I eventually just re-wrote most if it in X11 (which was such a pain). I will see if an updated version is helpful in a week or two when I get a bit more free time.