Crash on closing window [SFML2]

[JAssange]

I found someone else with this issue in the French forum but as I don't know French well enough to communicate effectively I made a new thread here.

Upon closing my game I get an error:

Code: [Select]

The thread 'Win32 Thread' (0x1ca8) has exited with code 0 (0x0).
First-chance exception at 0x6903a4ca in Test.exe: 0xC0000005: Access violation reading location 0x00000054.
Unhandled exception at 0x6903a4ca in Test.exe: 0xC0000005: Access violation reading location 0x00000054.

This error occurs after main returns, eg. if I breakpoint return EXIT_SUCCESS; it hits the breakpoint before the error occurs, but once it exits main whatever code it jumps off into (a destructor?) throws an error. This happens even if I haven't allocated any Images or Fonts etc, and I don't have any custom destructors for my objects yet so I'm not entirely sure what's going on here.

The stack frame contains: opengl32.dll MakeNoCurrent and atiolgxx.dll with an unknown function.

My graphics card is an ATI Mobility Radeon HD 5870.

This wasn't happening to me with SFML 1.6 but I had to switch to SFML 2 due to the bug with sprite SubRects that made tilesets unusable.

In the French thread you mentioned needing to expose a cleanup call to the user to fix this, if I was going to modify the SFML code myself to fix this what do I need to do exactly in this cleanup function?

[Silvah]

It's the infamous ATI bug: dynamically linked SFML and ATI drivers don't like each other. I really wonder when it'll be fixed, it's a blocker, after all.

[Groogy]

Have you tried static link? Anyway this happens my integrated intel too. From my perspective, I would say that intel got bad drivers. But since you are also getting the same problem I don't know. The good thing is that when running the application outside VS the error won't appear.

[JAssange]

Since this issue only appears when debugging in Visual Studio I've fixed it by adding this right before my return EXIT_SUCCESS;

Code: [Select]

#ifdef _WIN32
#ifdef DEBUG
TerminateProcess(GetCurrentProcess(), EXIT_SUCCESS);
#endif
#endif


Requires conditionally including Windows.h:

Code: [Select]

#ifdef _WIN32
#ifdef DEBUG
#include <Windows.h>
#endif
#endif

[Groogy]

That's pretty sweet, I'll try that out at home too.

Would make development so much easier

[JAssange]

That's pretty sweet, I'll try that out at home too.

Would make development so much easier

Just a note, the DEBUG define that it relies on is something I manually added to preproccessor defines for debug mode as VS wasn't defining _DEBUG for me like it's supposed to.

[eXpl0it3r]

I get a similar error, but I use an Intel Mobile graphics card...
What's interessting, when I don't define the /SUBSYSTEM Windows parameter for the linker, I don't get an error (but a console window).
As soon as I add the subsystem I get the error and the debugger puts me into the file dbgheap.c...
But when I debug everything after the 'return' statement of the main() function, I end up in the functin crtExitProcess (crt0dat.c) which then calls ExitProcess(status). Just after that call, the programm crashes and the debuger jumps again to the dbgheap.c, but then the error either had to be occured before the crash, or I don't understand how it can occure when this function wasn't even called at the time of the crash...

Strange thing. I hope Laurent will fix it soon, until then I just won't use the subsystem thing. :-P

[Laurent]

I hope Laurent will fix it soon

I might start implementing something very soon

finally

[eXpl0it3r]

finally

 :lol:

Do you know then why the errors occure, or what are you gonna write? ;-)
Did you ever talk to ATI? :-P

[JAssange]

finally

 :lol:

Do you know then why the errors occure, or what are you gonna write? ;-)
Did you ever talk to ATI? :-P

Assuming the little bit of French I know was correct I believe in the French thread about this he said that the issue is that SFML has a global OpenGL context to keep images/soundbuffers etc even when you recreate the window but there is no way to ensure it is destroyed without a manual call that SFML does not expose to init and destroy the context in your program.

[Laurent]

That's more or less the problem.

In fact SFML has a global OpenGL context, which is constructed before main() and destroyed after. This is what badly mixes with ATI drivers (don't know why, the driver DLL is properly loaded at that time). So I need to modify it so that it is both constructed and destroyed inside main(), either with some automagic stuff in SFML or by user intervention.

what are you gonna write?

More about this after I try what we're talking about on the french forum

[eXpl0it3r]

More about this after I try what we're talking about on the french forum

Okay ;-)
I should understand French, but I don't like it. xD

[phoekz]

Is there any update on this particular issue? I have this exact problem . I have ATI drivers and compiling on Visual Studio as well. Using Win7 and SFML2.

I noticed that this might be somewhat related to drawing text to the screen. Crashes started appearing right after I implemented interface for a game. I started commenting bits of this new code I just wrote (trying to isolate the cause of problem) and came to conclusion that if I don't draw any text to screen, I don't get any problem.

It is nothing major since on release builds it never crashes, but it would be nice if it doesn't happen while debugging .

[Laurent]

Yep, the ATI fix is implemented but it still crashes when you use the default font.

[phoekz]

It works now, thanks man .