SFML breaks, trying to free the default font

[nitram_cero]

It happens when I close the window (i.e.: sf::RenderWindow::Close())
There is no OpenGL Context when "dying", and so the default font tries to get it and then everything breaks.

This didn't happen with revision 959.

Info:

SVN Version: r1079 (also happens with SFML 1.4)
Graphics Card: Ati Radeon 9800 pro / Driver: v6.14.0010.6833
OS: Windows XP SP2

File: sfml-svn\trunk\src\SFML\Window\Win32\WindowImplWin32.cpp
Line: 298

Call Stack:

Code: [Select]

atioglx2.dll!016f91f5()
  [Frames below may be incorrect and/or missing, no symbols loaded for atioglx2.dll]
  atioglxx.dll!6932a17a()
  opengl32.dll!_MakeAnyCurrent@16()  + 0x150 bytes
  opengl32.dll!_wglMakeCurrent@8()  + 0x8a bytes
> sfml-window-d.dll!sf::priv::WindowImplWin32::SetActive(bool Active=true)  Line 298 + 0x1c bytes C++
  sfml-window-d.dll!sf::Context::SetActive(bool Active=true)  Line 64 + 0x18 bytes C++
  sfml-graphics-d.dll!sf::priv::GraphicsContext::GraphicsContext()  Line 69 C++
  sfml-graphics-d.dll!sf::Image::DestroyTexture()  Line 776 + 0x8 bytes C++
  sfml-graphics-d.dll!sf::Image::~Image()  Line 117 C++
  sfml-graphics-d.dll!sf::Font::~Font()  + 0x63 bytes C++
  sfml-graphics-d.dll!`sf::Font::GetDefaultFont'::`2'::`dynamic atexit destructor for 'DefaultFont''()  + 0x28 bytes C++
  sfml-graphics-d.dll!_CRT_INIT(void * hDllHandle=0x10000000, unsigned long dwReason=0, void * lpreserved=0x00000001)  Line 449 C
  sfml-graphics-d.dll!__DllMainCRTStartup(void * hDllHandle=0x10000000, unsigned long dwReason=0, void * lpreserved=0x00000001)  Line 560 + 0x11 bytes C
  sfml-graphics-d.dll!_DllMainCRTStartup(void * hDllHandle=0x10000000, unsigned long dwReason=0, void * lpreserved=0x00000001)  Line 510 + 0x11 bytes C
  ntdll.dll!_LdrpCallInitRoutine@16()  + 0x14 bytes
  ntdll.dll!_LdrShutdownProcess@0()  + 0x142 bytes
  kernel32.dll!__ExitProcess@4()  + 0x42 bytes
  kernel32.dll!7c81cab6()
  msvcr90d.dll!___crtExitProcess()  + 0x1b bytes
  msvcr90d.dll!___freeCrtMemory()  + 0x321 bytes
  msvcr90d.dll!_exit()  + 0x12 bytes
  game.exe!__tmainCRTStartup()  Line 599 C
  game.exe!WinMainCRTStartup()  Line 403 C
  kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes



Regards
-Martín

[Laurent]

Hi

Thanks for the detailed report, but this is the oldest known bug in SFML so I already know this

However I don't think it's related to the context being destroyed when the font tries to use it. Actually, the OpenGL context is never destroyed.

[nitram_cero]

Sorry I posted here. The Graphics forum says "Help", and I thought it was for "How do I...?" questions.

I'll try to get to the root of the problem.
If I find any solution I'll post it here.

Regards
-Martín

[nitram_cero]

Found the problem.

Code: [Select]

void WindowImplWin32::ProcessEvent(UINT Message, WPARAM WParam, LPARAM LParam)
{
    //...
    switch (Message)
    {
        // Destroy event
        case WM_DESTROY :
        {
            // Here we must cleanup resources !
            Cleanup();
            break;
        }


Code: [Select]

void WindowImplWin32::Cleanup()
{
    //...

    // Destroy the OpenGL context
    if (myGLContext)
    {
        // Unbind the context before destroying it
        SetActive(false);

        wglDeleteContext(myGLContext);
        myGLContext = NULL;
    }


 :wink:


This is called (callback'd) after win->Close(); or delete win; (Being win a valid RenderWindow)

GraphicContext constructor (GraphicContext.cpp Line 63) re-creates a context out of thin air calling Context::GetGlobal().
Then (I assume) it breaks when trying to free an image from a different context.

You should defer the context deletion after everything else, instead of on the window destroyal.

I would edit and fix the code but I don't have "the big picture" to know where to put it, so I leave it up to you.

It has to be something to do with the order, because if I leave the window opened and never delete it, my app doesn't crash.

Also found a bug (SVN-patch @ http://nitram.cero.googlepages.com/patch_sfml_nitram_2009_05_04.patch)

Regards
-Martín[/code]

[Laurent]

You should defer the context deletion after everything else, instead of on the window destroyal.

This is just the context owned by the window. There is another one which is, like I said, never destroyed. And they all share their display lists so that a resource created with one can be destroyed with another. So I still don't see the problem here, that's weird.

Also found a bug (SVN-patch @ http://nitram.cero.googlepages.com/patch_sfml_nitram_2009_05_04.patch)

Hmm? What bug does this solve?

[nitram_cero]

You should defer the context deletion after everything else, instead of on the window destroyal.

This is just the context owned by the window. There is another one which is, like I said, never destroyed. And they all share their display lists so that a resource created with one can be destroyed with another. So I still don't see the problem here, that's weird.

Also found a bug (SVN-patch @ http://nitram.cero.googlepages.com/patch_sfml_nitram_2009_05_04.patch)

Hmm? What bug does this solve?

If I skip the Cleanup() (while tracing, "Set next statement"), then it does not break.
So yeah, that's where the problem is coming from. Maybe it's a bad ATI implementation... but anyway it's to be taken in serious consideration.

It's not good that for 30% of Windows players, your game crashes on exit.

The bugfix fixes deleting a NULL pointer. Even if it doesn't crash because the delete operator is NULL-friendly it's not a good coding habit.

Regards
-Martín

[Laurent]

If I skip the Cleanup() (while tracing, "Set next statement"), then it does not break.
So yeah, that's where the problem is coming from

Interesting. That doesn't explain the bug, but it's a good starting point for more debugging. Thanks for your help

The bugfix fixes deleting a NULL pointer. Even if it doesn't crash because the delete operator is NULL-friendly it's not a good coding habit.

I don't think so, I have absolutely no problem deleting a null pointer. At least it saves a condition (ok, it's not really relevant).

[nitram_cero]

The bugfix fixes deleting a NULL pointer. Even if it doesn't crash because the delete operator is NULL-friendly it's not a good coding habit.

I don't think so, I have absolutely no problem deleting a null pointer. At least it saves a condition (ok, it's not really relevant).

My mistake, sorry. I just didn't knew that it was part of the standard.

[MadMartin]

Thanks for the detailed report, but this is the oldest known bug in SFML so I already know this

Any news on this one?

[Laurent]

It will be working very soon in the SFML 2.0 branch.

[MadMartin]

Yeah, that's cool.


Don't give up the good work, Laurent  :wink:

[drpitch]

Hi all,

It's happening the same to me..It crashes when the application finishes and SFML is freeing all resources (freeing the default font).

This minimal sample application crashes:

Code: [Select]


#include <SFML/System.hpp>
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
int main()
{
   sf::String text;
   return 0;
}



Call stack:

Code: [Select]


  atioglxx.dll!69029503()
  [Frames below may be incorrect and/or missing, no symbols loaded for atioglxx.dll]
  opengl32.dll!5f145709()
  opengl32.dll!5f139aad()
  opengl32.dll!5f139c5f()
> sfml-window-d.dll!sf::priv::WindowImplWin32::SetActive(bool Active=true)  Line 302 + 0x1c bytes C++
  sfml-window-d.dll!sf::Context::SetActive(bool Active=true)  Line 64 + 0x18 bytes C++
  sfml-graphics-d.dll!sf::priv::GraphicsContext::GraphicsContext()  Line 69 C++
  sfml-graphics-d.dll!sf::Image::DestroyTexture()  Line 776 + 0x8 bytes C++
  sfml-graphics-d.dll!sf::Image::~Image()  Line 117 C++
  sfml-graphics-d.dll!sf::Font::~Font()  + 0x63 bytes C++
  sfml-graphics-d.dll!`sf::Font::GetDefaultFont'::`2'::`dynamic atexit destructor for 'DefaultFont''()  + 0x28 bytes C++
  sfml-graphics-d.dll!_CRT_INIT(void * hDllHandle=0x007f0000, unsigned long dwReason=0, void * lpreserved=0x00000001)  Line 446 C
  sfml-graphics-d.dll!__DllMainCRTStartup(void * hDllHandle=0x007f0000, unsigned long dwReason=0, void * lpreserved=0x00000001)  Line 557 + 0x11 bytes C
  sfml-graphics-d.dll!_DllMainCRTStartup(void * hDllHandle=0x007f0000, unsigned long dwReason=0, void * lpreserved=0x00000001)  Line 507 + 0x11 bytes C
  ntdll.dll!7c91118a()
  ntdll.dll!7c933ada()
  ntdll.dll!7c920435()
  ntdll.dll!7c92043e()
  ntdll.dll!7c933c88()
  kernel32.dll!7c81cb26()
  msvcr90d.dll!__crtExitProcess(int status=0)  Line 732 C
  msvcr90d.dll!doexit(int code=0, int quick=0, int retcaller=0)  Line 644 + 0x9 bytes C
  msvcr90d.dll!exit(int code=0)  Line 412 + 0xd bytes C
  main.exe!__tmainCRTStartup()  Line 595 C
  main.exe!mainCRTStartup()  Line 399 C
  kernel32.dll!7c817077()
  main.exe!__CTA1?AVexception@std@@()  + 0x86bd bytes C++
  c7fff6b9()


My video card is an ATI Radeon 9550.

[Laurent]

It's happening the same to me..

Of course it is, it is fixed only in the SFML 2.0 branch

[drpitch]

I'm happy to hear that is fixed on 2.0 branch
Meanwhile, I'll remove the Cleanup()  sentence from WindowImplWin32::ProcessEvent method.

Thanks Laurent