sf::RenderTexture destructor causes a crash

[Laurent]

Since you're the only one to report such an issue, it is likely that there's a problem with your environment rather than in SFML. I have no idea what I could do to help you.

[binary1248]

Learn to use a debugger. Yes... a debugger, not Windows, a debugger. It isn't invoked automatically and whenever Windows gives you those error messages it actually has nothing to do with debugging whatsoever. Build your test program in debug build and link it to the SFML debug libraries. When you have done that, run it in the Visual Studio Debugger (yes there is a special button/menu for this and it is not the same as running it normally, look for it). When Visual Studio lights up like a Christmas tree and some SFML source file gets displayed in your main editor window take a screenshot and post it here.

Have fun.

[wogoo]

What are you saying? Please keep your frustration out.

So, i have no problems with native OpenGL framebuffers, neither with SDL ones and i think that it's a way to fix it, but since i'm the only with this issue it's comprensible this is not a priority. And i'm forced to pass over SFML at this point.

[Nexus]

Please consider binary1248's advice. Since we are not able to reproduce the issue*, the only thing that potentially helps us fixing it is when you debug the code and tell us where and why it crashes.

And triple-check your configuration, especially when you say framebuffer objects work with SDL and raw OpenGL. It would be a pity to waste time if there's simply a linking mistake...

___________
* I just tested the code in your initial post on an Intel HD Graphics 3000.

[binary1248]

What are you saying? Please keep your frustration out.

It's kind of hard considering the majority of these "crash bug reports" consist of some generic Windows error message and a description of what could have led to it. Simply using the debugger to narrow down the cause of the crash can help you and us to get your code running and even fix SFML if this is a legitimate bug. Every IDE and compiler toolchain comes with a debugger so there is no real excuse whatsoever not to use them. Most people have no idea what a debugger is, thinking that debugging their code is a matter of trial and error. Some even go so far as to call the Windows error messages debugger messages although they have nothing to do with each other.

So, i have no problems with native OpenGL framebuffers, neither with SDL ones and i think that it's a way to fix it, but since i'm the only with this issue it's comprensible this is not a priority. And i'm forced to pass over SFML at this point.

This makes it even more important to fix this issue if what you say is true and you can use OpenGL Framebuffer Objects directly but not through SFML. Also, what most people forget is that SDL has multiple render backends, and on Windows it defaults to using a Direct3D backend with HEL suppport so saying something "works with SDL but not SFML" doesn't really help much. (Maybe at some point in the distant future Laurent might think of providing more render backends since this is a deal breaker for many.)

So Laurent do you think this issue can be solved?
If you want i can test some code on my computer, or whatever you need.

Sincerely i haven't much time to switch to another framework right now, and also i think SFML is better that other C++ "competitors".

If you think SFML is better than its competitors, then surely you want to contribute to make it even better right? If everybody just gave up after some obscure crash, SFML wouldn't be where it is today. And in case you think Laurent is the only one who can fix problems, many bugs get discovered and some even fixed by the community. He is the one who implements them into SFML if nobody submits a patch for him to review.

[wogoo]

I have used the debugger obviously, and if i haven't post any detail about the crash is because there aren't.
It's a ntdll.dll crash, and without a PDB file no source file gets displayed.

[Nexus]

Thus, in the callstack, there is directly a DLL call below sf::RenderTexture::~RenderTexture()? Does it crash in a specific line of the destructor, or during automatic cleanup of member variables?

It would be nice if you could post as much information as possible (e.g. callstack). Also, can't you reduce your initial code any further without making the crash disappear?

[binary1248]

Even the best debugger can't really do much if you are trying to debug without any symbols, I thought this point was kind of obvious...

Build SFML in debug mode, it will generate the required PDBs, then build your application in debug mode as well, and link to the debug SFML libraries.

It's a ntdll.dll crash

Almost everytime something crashes in Windows it is either in ntdll.dll, some runtime library or some driver .dll... This doesn't mean anything useful.

[wogoo]

There are SFML .pdb files, but not ntdll.dll ones, i've uploaded my project and Laurent said it's ok, i've linked correct debug libraries.
This is my ouput:

Code: [Select]

'TestSfml.exe': Loaded 'Path\TestSfml\Debug\TestSfml.exe', Symbols loaded.
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\opengl32.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\msvcrt.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\advapi32.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\sechost.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\rpcrt4.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\sspicli.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\cryptbase.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\gdi32.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\user32.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\lpk.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\usp10.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\glu32.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\ddraw.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\dciman32.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\setupapi.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\cfgmgr32.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\oleaut32.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\ole32.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\devobj.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\dwmapi.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\winmm.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\msvcp100d.dll', Symbols loaded.
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\msvcr100d.dll', Symbols loaded.
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\imm32.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\msctf.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\uxtheme.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\ig4icd32.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\dinput.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\hid.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\wintrust.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\crypt32.dll', Cannot find or open the PDB file
'TestSfml.exe': Loaded 'C:\Windows\SysWOW64\msasn1.dll', Cannot find or open the PDB file
And so SFML symbols are loaded correctly.

I noticed a line in the output that can be useful:
Invalid address specified to RtlFreeHeap("useless since it changes everytime", 03740730)
The invalid address is not the RenderTexture address, the second parameter are internal flags.

The call stack is:
->   ntdll.dll!77ea0724()    
    ntdll.dll!77e6295a()    
    ntdll.dll!77ea177f()    
    ntdll.dll!77e5a967()    
>   ntdll.dll!77e09f15()    
'RenderTexture::create' mess up the memory and the application crashes when deleting the renderTexture.

[Nexus]

And so SFML symbols are loaded correctly.

Where do you conclude that from? According to your output, only the symbols of your application and the MSVC runtime libraries are loaded.

Also, if that is your whole callstack, you are certainly missing debug symbols. Make sure you really compile in Debug mode and use original MSVC project settings.

'RenderTexture::create' mess up the memory

Again, how do you know that? Undefined behavior may be tricky, don't be tempted to draw the obvious conclusions...

[wogoo]

Because if i compile in release mode i get also:

Code: [Select]

'TestSfml.exe': Loaded 'Path\TestSfml\Release\sfml-graphics-2.dll', Binary was not built with debug information.
'TestSfml.exe': Loaded 'Path\TestSfml\Release\sfml-window-2.dll', Binary was not built with debug information.
'TestSfml.exe': Loaded 'Path\TestSfml\Release\sfml-system-2.dll', Binary was not built with debug information.

Regarding the second question, i get a crash also on a sf::Texture destructor only if before i create a RenderTexture.

[Ixrec]

That explicitly says you don't have the debug info/symbols, so no they are not getting loaded correctly.

Since those reveal that you're using binaries instead of compiling from source, you should go get the sources.  It's impossible to debug a library without compiling its source code in debug mode yourself.  Otherwise we'll never know what part of the destructor you're crashing on.

[eXpl0it3r]

That explicitly says you don't have the debug info/symbols, so no they are not getting loaded correctly.

Since those reveal that you're using binaries instead of compiling from source, you should go get the sources.  It's impossible to debug a library without compiling its source code in debug mode yourself.  Otherwise we'll never know what part of the destructor you're crashing on.

I nearly got that wrong as well...
Afaik, he assumes because VS complains when running the application through the debugger in release modes, the symbols will get loaded in debug mode. Which is a false assumption. Release and Debug use two different kind of settings, thus just because it complains in release mode that there isn't any debug information (which is true), doesn't mean that the debug symbols actually exists nor does it mean that they get loaded.

On the issue itself, just set a break point before the destructor and step into it. VS's debugger is dead simple to use in that case and is often rather strong a resolving variables etc.

[wogoo]

I think i've found the cause of this issue.

I've discovered that the crash happens on 'glDeleteTextures' function, but it's really curious that it happens only on sf::RenderTexture destructor and not on sf::Texture one.
So i tried to create a Sf::Texture on a separate thread (sf::Thread) and i got the crash.

I have not looked at SFML source and i don't know if it's loaded on a separate thread, please let me know, it could finally explain this issue.

I've also found some other threads about this issue, for example:
http://en.sfml-dev.org/forums/index.php?topic=2961.0

[binary1248]

This is probably the next iteration of context juggling crashes.

The problem here is that when the sf::RenderTexture is destroyed, its context is destroyed before its texture is. When the context gets destroyed there is none left active, in this case SFML sets the current context to the internal one in the sf::Texture destructor. So in effect, you are creating the sf::Texture in one context and destroying it in another (the internal thread local context, even more dubious). The same goes for the crash when mixing sf::Texture and sf::Thread (every thread has its own thread local context, to enable OpenGL usage from more than one thread, for those who somehow need it). To make it even more interesting, we might not know if the context is properly destroyed (or even if it is destroyed on time) so that resources can be propagated to the shared context. Another thread might be using the context to do "something" without SFML's knowledge, and trying to delete the texture while in use will always result in a crash.

Because resources should be shared (with all the synchronization etc.), this shouldn't be a problem, however I've had my share of strange bugs regarding resource sharing across multiple contexts. I've developed a habit of making all my context management explicit when it comes to these sticky situations because relying on SFML doing everything automatically is just asking for a random crash at an unfortunate moment.

The sad part is that it might not even be SFML's fault that it crashes. Buggy drivers (from all vendors) and broken Intel cards along with the joke of documentation provided by Microsoft makes it almost impossible to understand or even reproduce this behaviour consistently.

I've already pushed for getting rid of the shared context ordeal in order to remove this source of bugs, but people seem to still have a need for it, or are unwilling to take care of context management on their own.

Possible source of bugs:
wglMakeCurrent( NULL, NULL ) is broken.
Resource sharing is broken.
Driver is broken.
Hardware is broken.
Thread Local Storage in combination with contexts is broken.

Take your pick. I already gave up looking for the cause a long time ago. It doesn't seem like those who maintain any of those sources seems to care about use cases such as SFML. The only thing SFML can do is to jump on the train and use those facilities like everyone else does in order to have an easier time getting support.