Results 1 to 5 of 5

Thread: relationship between GC and Texture?

  1. #1

    Default relationship between GC and Texture?

    Hi. Check this out:
    Code:
    {
    vector<CL_Texture> v;
    CL_DisplayWindow w("", 0, 0);
    v.push_back(CL_Texture(w->get_gc(), 0, 0));
    }
    What happens here?
    Careless coder declares a vector. AFTER that he creates a window. Then he goes on to make himself a texture. He plans to iterate over the vector later, and draw his textures.
    Now we go out of scope. The window was declared last so it's destructed FIRST. The gc becomes invalid. Vector goes out of scope, destructs its texture, we call clDeleteTextures on an invalid gc_provider. Segfault, bang, we're dead.

    If the vector was declared after the window, this wouldn't happen. But it's really error prone and not obvious where the crash comes from. The API shouldn't let me do this stuff.

    How should we solve this? The GC could keep a list of all its textures, then notify all of them when it's destructed. They take note and set a flag which they check before doing clDeleteTextures in the dtor.

    This sounds inefficient, cause the GC would waste memory on safe-netting me. Still IMO it's worth it. What do you think?

    Cheers
    Stefan

  2. #2
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    This is a known problem.

    I have encountered it myself in a different situation (whilst writing the CL_BitmapFont class).

    The CL_Texture implementation should be able to be tracked by the display window implementation; using a ClanLib weak pointer from CL_Texture to the display window and CL_Texture reference counts.

    So, if the display window is destroyed whist a CL_Texture is active, an exception is thrown.

    ... Humm maybe not

    CL_Texture should know if CL_GraphicContext is valid at all times?
    Last edited by rombust; 07-02-2008 at 11:14 AM. Reason: (Added ...humm maybe not)

  3. #3
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    Fixed in latest SVN. It now displays a warning, if the programmer deallocates the textures in the incorrect order.

  4. #4

    Default

    Ok that's great but another problem remains, look:

    Code:
    CL_GraphicContext gc;
    int main() {
    	CL_SetupCore setupCore;
    	CL_SetupDisplay setupDisplay;
    	CL_SetupGL setupGl;
    	vector<CL_Texture> v;
    	CL_DisplayWindow w("", 0, 0);
    	gc = w.get_gc();
    	v.push_back(CL_Texture(gc, 0, 0));
    }
    So when I have a global gc handle and I put the window gc into it, the weakptr to gc becomes null too late (after main is over) and the check isn't triggered so I segfault. What do you say, how should this be handled? Is it just my fault for using globals?
    (note: that's real code I wrote in my game and had to debug)

  5. #5
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    Yeah, you should not use globals

    It would be possible to fix, to throw a warning, in the same way as in the CL_Texture destructor.

    CL_GraphicContext should not exist after the display was destroyed.

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •