~Image() crash -sfml2.0

[arpeggiodragon]

I will sometimes get a crash from the Image destructor on program exit. "Sometimes" as in not very often, but occasionally.  -MSVC 2008 _DEBUG setting.

Here is the main function with non-SFML code removed:

Code: [Select]


int main()
{
sf::RenderWindow window(sf::VideoMode(640, 480), "SFML OpenGL" );

sf::Image tilesheet;
if (!tilesheet.LoadFromFile("image.png"))
          return -123;

  // create OpenGL texture with tilesheet.GetPixelsPtr()
 
  // -main loop
  {
  // OpenGL code here
window.SaveGLStates();
{
window.Draw(text);
}
window.RestoreGLStates();

window.Display();
  }
  return 0;
}


[Laurent]

Do you use the SFML debug libraries (-d suffix) in debug mode?

[arpeggiodragon]

Yes.
- sfml-main-d.lib sfml-system-s-d.lib sfml-window-s-d.lib sfml-graphics-s-d.lib opengl32.lib glu32.lib
- Minimal rebuild.

I take it this may not be a common issue then? I'll see about getting a stack trace next time it happens.

[Laurent]

- Minimal rebuild.

Try "rebuild all".

I take it this may not be a common issue then? I'll see about getting a stack trace next time it happens.

Good. You can also tell me which revision of SFML 2 you're using, and if it always happened before of if you can find one that doesn't crash.

[arpeggiodragon]

HEAP[Tests.exe]: Invalid Address specified to RtlFreeHeap( 00150000, 08C64750 )

    Tests.exe!sf::Image::DestroyTexture()  + 0x66 bytes   
    Tests.exe!sf::Image::~Image()  + 0x51 bytes   
>   Tests.exe!main()  Line 349 + 0x19 bytes   C++
    Tests.exe!_WinMain@16()  + 0x19 bytes   C++
    Tests.exe!__tmainCRTStartup()  Line 574 + 0x35 bytes   C
    Tests.exe!WinMainCRTStartup()  Line 399   C

This is the best I can do as I have no program database files for SFML. (didn't think I would need them you know)

I'm using the 2.0 snapshot from about 3-4 weeks ago. Also I've since removed all other SFML rendering code, including .Draw(text) calls, though I don't know why that would matter any.

Are you calling glDeleteTextures() there?

[Laurent]

This is the best I can do as I have no program database files for SFML

You must have them because you compiled SFML yourself. If you removed them, recompile it again

[arpeggiodragon]

Nah, don't need to go through all that. Here's yer problem:

Code: [Select]


void Image::DestroyTexture()
{
    // Destroy the internal texture
    if (myTexture)
    {
        GLuint Texture = static_cast<GLuint>(myTexture);
        GLCheck(glDeleteTextures(1, &Texture));
        myTexture        = 0;
        myTextureUpdated = true;
        myArrayUpdated   = true;
    }
}

Surely a dtor is about the worst possible place to put that.

(True, this probably would simply be undefined on my NVidia card, but still...)

[Nexus]

Surely a dtor is about the worst possible place to put that.

Why? It's the only way to allow RAII. In this respect, I consider the destructor the best place.

Where would you put the deallocation of the texture? Would you force the user to call an explicit function before every sf::Image is destroyed?

[arpeggiodragon]

It's the only way to allow RAII. In this respect, I consider the destructor the best place.

No, I'm afraid you are wrong in this case: http://www.opengl.org/wiki/Common_Mistakes

At best; trying to clean up resources when there is no OpenGL context does nothing anyway.

Where would you put the deallocation of the texture? Would you force the user to call an explicit function before every sf::Image is destroyed?

I just stuck it right before the window.Close(); function. Works fine for me.


Also there should be an GLuint sf::Image::GetTexture() function, but there doesn't seem to be.

[Laurent]

Well, have you looked at SFML sources, or done any test before saying that we're wrong and that there's no OpenGL context?

There is always a valid OpenGL context, even when all windows have been destroyed. So it doesn't matter where you call OpenGL functions (except at global startup and exit).

I just stuck it right before the window.Close(); function. Works fine for me.

Can you please show a complete and minimal example that doesn't work, and the same one with your "fix"? So that I can test it and see what's wrong.

Also there should be an GLuint sf::Image::GetTexture() function, but there doesn't seem to be.

You would like to have such a function, which is totally different than "there should be"

[arpeggiodragon]

No, sorry I wasn't clear about that. What I mean is this is not a bug in SFML but with my Intel drivers. It shouldn't cause a crash there AFAIK, even though it sometimes does. This is properly fixed in this case (for me that is) by making myTexture public. This makes me wonder just how card manufacturers decide to implement these functions... And just how often, and on what cards, will calling glDeleteTextures actually do anything on exit? ..Ideally it would delete the textures I suppose.


@GetTexture. Sure, but it would take one line of code and let users do this:
glBindTexture( GL_TEXTURE_2D, sf::Image::GetTexture() );
// draw a gluQuadric or something

[Laurent]

They can already do that:

Code: [Select]

image.Bind();

Giving access to the internal texture for something else would make less sense. But anyway, as OpenGL is a state machine, once the texture is bound you can do whatever you want on it. The only thing that you can't do without the internal handle is to destroy it