SFML community forums
Help => General => Topic started by: ravenheart on January 02, 2011, 06:17:05 pm
-
I get a segmantation fault when closing a SFML window-application.
Im using sfml 2 on a 64bit linux.
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "��
after 7131 requests (7130 known processed) with 0 events remaining.
Segmentation fault
Not sure what it means exactly
-
Don't you have a radeon graphics card? AFAIK, there are some problems with linux radeon drivers.
-
Only on Windows, as far as I know.
-
It is a Radeon 4870 with fglrx driver.
Opengl Version 3.3.xxx
GLSL 3.3
-
I have the same problem, with SFML 2 from Github.
Using Ubuntu 10.10 with an ATI card:
Renderer: ATI Radeon HD 4300/4500 Series
Version: 3.3.10237 Compatibility Profile Context
Error is:
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "PX6"
after 152 requests (151 known processed) with 0 events remaining.
Here is my stack trace:
#8 0x00007ffff5d967f4 in _XDefaultIOError () from /usr/lib/libX11.so.6
#9 0x00007ffff5d9686e in _XIOError () from /usr/lib/libX11.so.6
#10 0x00007ffff5d9e415 in ?? () from /usr/lib/libX11.so.6
#11 0x00007ffff5d9e9b0 in _XReply () from /usr/lib/libX11.so.6
#12 0x00007ffff5d8bdbd in XQueryExtension () from /usr/lib/libX11.so.6
#13 0x00007ffff5d80202 in XInitExtension () from /usr/lib/libX11.so.6
#14 0x00007ffff5933782 in XextAddDisplay () from /usr/lib/libXext.so.6
#15 0x00007ffff7e61fbb in AtiCallFGLComposite () from /usr/lib/fglrx/libGL.so.1
#16 0x00007ffff0d4eb73 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#17 0x00007ffff0da4c84 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#18 0x00007ffff0b80b26 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#19 0x00007ffff0405fd8 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#20 0x00007fffef9b5a23 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#21 0x00007fffefa67cf7 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#22 0x00007fffefa67e69 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#23 0x00007ffff040b2bd in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#24 0x00007ffff0d51df7 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#25 0x00007ffff0d52751 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#26 0x00007ffff0d527ad in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#27 0x00007ffff7e3c909 in ?? () from /usr/lib/fglrx/libGL.so.1
#28 0x00007ffff7e3c94a in ?? () from /usr/lib/fglrx/libGL.so.1
#29 0x00007ffff5d782d5 in _XFreeExtData () from /usr/lib/libX11.so.6
#30 0x00007ffff5d8590d in _XFreeDisplayStructure () from /usr/lib/libX11.so.6
#31 0x00007ffff5d70eaf in XCloseDisplay () from /usr/lib/libX11.so.6
#32 0x000000000327d59a in sf::priv::WindowImplX11::~WindowImplX11 (this=0x5129b10, __in_chrg=<value optimized out>)
at ../../../externals/sfml/src/SFML/Window/Linux/WindowImplX11.cpp:268
#33 0x000000000327d609 in sf::priv::WindowImplX11::~WindowImplX11 (this=0x5129b10, __in_chrg=<value optimized out>)
at ../../../externals/sfml/src/SFML/Window/Linux/WindowImplX11.cpp:269
#34 0x000000000327256a in sf::Window::Close (this=0x4b66b70) at ../../../externals/sfml/src/SFML/Window/Window.cpp:160
#35 0x000000000324190c in scape::sfml::SFMLDisplay::close (this=0x4b826a0) at ../../../scape/modules/sfml/sfmldisplay.cpp:126
Any ideas?
Thanks!
[/code]
-
I just tested on a Mint 11 (Gnome, 64bit) with a Radeon HD 5750:
Renderer: ATI Radeon HD 5700 Series
Version: 4.1.10665 Compatibility Profile Context
Works fine here, so it's seems to be driver-related, like you mentioned in another topic. Thing is, it works on the bad driver when I use SDL 1.2. Either SDL is using a different X11 interface, or it has some kind of workaround for this bug.
So is this bug supposed to be fixed in SFML 2? I'd really hate going back to SDL...
Thanks so much, SFML 2 is awesome, and otherwise really stable for pre-release software!
-
SDL 1.2 doesn't use OpenGL at all. Try SDL 1.3 with the "OpenGL" renderer instead.
-
Thanks for the quick reply!
What I actually meant was that SDL 1.2 creates an OpenGL context if you pass it the SDL_OPENGL flag. I'm using SFML (and previously SDL) just for giving me a window with an OpenGL context on Mac and Linux. All the rendering is done using OpenGL directly, so for me the difference between SDL and SFML is just how the X11 window and the OpenGL context are handled.
-
Oh ok, I see.
-
Sorry for the thread necromancy, but I still see this bug in SFML 2 RC1. This time on a Ubuntu 10.10 box with a GeForce 8400GS and Nvidia drivers 260.19.06.
The strange thing is, that it crashes even if I don't use SFML at all. I have a statically linked binary with both SDL and SFML (don't ask). Only SDL code is used, and I get the crash after closing the SDL window. If I link the executable without SFML, or with SFML 1.6, everything's fine.
-
Can you show the stack trace?
-
Should've mentioned the program doesn't crash, it just calls exit(), returning 1 as exit code. This makes my automated tests fail, so to me it's as bad as a crash. Judging from the stack trace, it seems the X11 calls fail because they're happening too late in the static deinitialization phase.
#1 0x00007ffff57fe1d4 in _XDefaultIOError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2 0x00007ffff57fe41e in _XIOError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007ffff57fc38b in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4 0x00007ffff57f7aed in XSync () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff57d8810 in XCloseDisplay () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x0000000004aa9b75 in (anonymous namespace)::GlobalDisplay::~GlobalDisplay (this=0x64f9d30, __in_chrg=<optimized out>) at ../../../externals/sfml/src/SFML/Window/Linux/InputImpl.cpp:47
#7 0x00007ffff5142921 in __run_exit_handlers (status=0, listp=0x7ffff54bd688, run_list_atexit=true) at exit.c:78
#8 0x00007ffff51429a5 in __GI_exit (status=<optimized out>) at exit.c:100
#9 0x00007ffff5128774 in __libc_start_main (main=0x38903f9 <main(int, char const* const*)>, argc=2, ubp_av=0x7fffffffe278, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffffffe268) at libc-start.c:258
#10 0x000000000388f865 in _start ()
-
I thought there was no more X11 Display used in global scope, but there's still one used for global inputs (sf::Mouse and sf::Keyboard). I wish there was a cleaner solution, but I haven't found one yet.
However it seems from your stack trace that a X11 error is triggered, don't you have a debug message in the standard output?
-
Yes, the debug message is the same as for the original poster (minus segfault), that's why I resurrected this thread in the first place:
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
after 8 requests (6 known processed) with 0 events remaining.
When I run the app so that SDL doesn't create a window, the process exits successfully without any debug messages. This means this problem is very specific to my build, but it also means I cannot use SFML in my projects, as it has to quietly coexist with other libraries. I know it's a difficult design choice, but if I had to decide it I wouldn't do things like calling X11 without the host app being able to do anything about it. Just my 2 cents, though.
Thanks!
-
I know it's a difficult design choice, but if I had to decide it I wouldn't do things like calling X11 without the host app being able to do anything about it.
That sounds wise, but what modifications would it involve in the API? How would you handle that in code?
-
I don't know the context in which the GlobalDisplay instance is used well enough, but I'd either use some kind of lazy initialization method (like a Singleton), or have the user call an init() function manually, like SDL does. The latter would be my preferred route, although I'm a aware that's it's slightly opposed to the way your API is designed. I'd be happy with the Singleton, as long as it's a private interface, just the way it is now. One of the most basic C/C++ idioms should apply here, "you don't have to pay for what you don't use".
To fix the X11 stuff, I suggest a shutdown() function, which is responsible for destroying all SFML instances which are still alive. This is probably hard to implement in a clean way, but it would give users a surefire way to force all system calls to complete just before the end of main(), and to avoid the undeterministic static deinitialization mayhem.
Hopefully that did make sense...
-
In fact the init/cleanup functions are probably the only solution to this kind of problem. But, of course, I'd like to avoid them :)
-
I hate to necro this thread again, but I'm running into the same error (without a segfault).
Checking my /var/log/Xorg.0.log file, this shows up every crash, and is right after X start up stuff, and before X closes (because of the crash):
"WaitForSomething(): select: Invalid argument"
Googling "WaitForSomething()" comes up with people reporting the same error, for different reasons though. Though I did learn that it's a function used in X.
I've gotten the same error multiple times, though the application usually runs for a variable amount of time before X crashes.
Got the same crash when running this: http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=24781
SFML version: 2.1.0.4a300547f3-1 (appears to be the latest github commit)
System:
Arch Linux
Kernel: 3.12.6-1-ck x86_64
Window Manager: Openbox
X.org X Server: 1.14.5
Mesa Drivers: 10.0.2-1
-
After doing some more digging around, it turns out it is a Kernel/X issue (https://lkml.org/lkml/2012/8/31/1).
So far seems to be fixed after having upgraded to Kernel 3.12.7 and X.org 1.15.0.