Author Topic: [SFML2] Window crashes when calling destructor (ATI) (Read 9440 times)

MarsCoreTeam · « **on:** January 26, 2011, 12:01:23 pm »

Hey there,

ATI again. I updated SFML2 after a while and discovered some trouble in sf::Window/sf::RenderWindow. When calling the destructor (implicitly or explicitly), programs will crash with Segmentation Fault under ATI.
I wrote a short and very simple program to test the behavior:

Code: [Select]

# include <SFML/Window.hpp>

int main() {
    sf::Window App(sf::VideoMode(800, 600), "iCrash");
    return 0;
}

This leads to the following output:

Code: [Select]

XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server "���"
      after 115 requests (114 known processed) with 0 events remaining.
Segmentation fault

The call stack is as follows:

Code: [Select]

#0 0x7ffff653c518	XextFindDisplay() (/usr/lib/libXext.so.6:??)
#1 0x7ffff653bf85	??() (/usr/lib/libXext.so.6:??)
#2 0x7ffff653c13c	??() (/usr/lib/libXext.so.6:??)
#3 0x7ffff6965e72	XCloseDisplay() (/usr/lib/libX11.so.6:??)
#4 0x7ffff335df6b	ADL_Main_Control_Destroy() (/usr/lib/fglrx/libatiadlxx.so:??)
#5 0x7ffff50efa96	??() (/usr/lib/fglrx/dri/fglrx_dri.so:??)
#6 0x7ffff51e5048	??() (/usr/lib/fglrx/dri/fglrx_dri.so:??)
#7 0x7ffff3f1d5b5	??() (/usr/lib/fglrx/dri/fglrx_dri.so:??)
#8 0x7ffff4a64d77	??() (/usr/lib/fglrx/dri/fglrx_dri.so:??)
#9 0x7ffff4a6e7f1	??() (/usr/lib/fglrx/dri/fglrx_dri.so:??)
#10 0x7ffff53b7844	??() (/usr/lib/fglrx/dri/fglrx_dri.so:??)
#11 0x7ffff7e37909	??() (/usr/lib/fglrx/libGL.so.1:??)
#12 0x7ffff7e3794a	??() (/usr/lib/fglrx/libGL.so.1:??)
#13 0x7ffff696d2d5	_XFreeExtData() (/usr/lib/libX11.so.6:??)
#14 0x7ffff697a90d	_XFreeDisplayStructure() (/usr/lib/libX11.so.6:??)
#15 0x7ffff6965eaf	XCloseDisplay() (/usr/lib/libX11.so.6:??)
#16 0x7ffff79c8ed1	sf::priv::GlxContext::~GlxContext() () (/usr/lib/libsfml-window.so.2.0:??)
#17 0x7ffff6ed58c0	__cxa_finalize() (/lib/libc.so.6:??)
#18 0x7ffff79c4ef6	__do_global_dtors_aux() (/usr/lib/libsfml-window.so.2.0:??)
#19 (	0x0000000000000000 in ??() (??:??)

This consequently means that one cannot recreate a window, which is very bad (for example when switching from windowed to full screen mode).

Furthermore, another strange problem occurs when simply linking against sfml-window and/or sfml-graphics (additional to sfml-system): a simple program as

Code: [Select]

int main() {
    return 0;
}

will never return.

This really seems to be ATI related, because everything works fine on a NVIDIA-powered PC.

Best regards,
Felix

JAssange · « **Reply #1 on:** January 26, 2011, 12:30:47 pm »

I get crashes like this in debug mode but never in release, does this occur in release mode?

MarsCoreTeam · « **Reply #2 on:** January 26, 2011, 12:35:06 pm »

Quote from: "JAssange"

I get crashes like this in debug mode but never in release, does this occur in release mode?

Doesn't matter, it crashes anyways respectively runs forever.

Laurent · « **Reply #3 on:** January 26, 2011, 01:12:37 pm »

This is just the "regular" ATI bug, don't worry it'll be fixed soon.

tntexplosivesltd · « **Reply #4 on:** January 26, 2011, 10:46:06 pm »

What is the deal with this ATI bug? I've heard about it, but what actually is it?

Laurent · « **Reply #5 on:** January 26, 2011, 10:51:09 pm »

It happens on Windows. There are actually two bugs:
- a crash at global exit when using SFML DLLs; workaround is simple, use static libraries
- a freeze at global startup when using Catalyst drivers > 10.10; no workaround except downgrading the drivers

Brendon · « **Reply #6 on:** January 27, 2011, 03:24:31 am »

Is there a temporary hotfix we can possibly apply to the SFML code itself? (I'm guessing somewhere in the sfml-window initialization?)

Laurent · « **Reply #7 on:** January 27, 2011, 07:36:40 am »

http://www.sfml-dev.org/forum/viewtopic.php?p=25585#25585

This is for SFML 2. It is similar with SFML 1.6, but the global context is located somewhere else.

sivael · « **Reply #8 on:** February 09, 2011, 07:36:19 pm »

Actually it's not a problem with only SFML.
It's even more pronounced in UDK(Unreal Development Kit), yes, the tool to create Unreal3Engine-based games. It makes the whole computer hang. It's caused by something in drivers from catalyst 10.11, 10.12 and 11.1.
ATI should really upgrade their coders. Current ones don't do well enough xD

MarsCoreTeam · « **Reply #9 on:** February 27, 2011, 11:12:22 am »

Hey Laurent!

Don't want to be impatient... but have you made any progress on this topic? With ATI under Linux, window destructors still crash the application and on some ATI powered Windows machines still no window opens

Thanks a lot for your hard work!

Brendon · « **Reply #10 on:** February 27, 2011, 05:34:00 pm »

The ATI issue prevented some users from playing my game Atom Zombie Smasher; someone took a look and found a work-around solution for it.

http://www.kn00tcn.net/site/cities-in-motion-startup-crash-fix/

It's not a permanent solution, but as a quick hotfix it works nicely.

Laurent · « **Reply #11 on:** February 27, 2011, 08:52:38 pm »

What is this atigtkxx.dll file? (sorry if I missed the explanations, I had a quick look at the linked website and couldn't find them)

Brendon · « **Reply #12 on:** February 28, 2011, 02:48:30 am »

From what I understand, the file is from the ATI 10.4 driver. Placing the DLL in the executable's folder overrides your system's current ATI driver.

I should also note that this is not a universal fix. I still haven't been able to pinpoint the conditions, but on some systems it may cause the game to not run/run slowly.

Richy19 · « **Reply #13 on:** April 20, 2011, 05:05:17 pm »

Does anyone know if using the atigktxx.dll file linked in that site has any side effects to 32bit/XP users?

Brendon · « **Reply #14 on:** April 20, 2011, 05:31:07 pm »

The atigktxx workaround is definitely not a universal fix - some of my users reported major framerate problems when they included the file (removing the file then resolved the problem).

I was unable to identify the common cause among these users.