sf::Texture destructor segfault?

[Ruckamongus]

Hello all,

I made a little SpriteManager class which will handle sprites (and textures) loading and passing around. This is my add function:

signed int Phox::cSpriteManager::Add(const std::string& Path, bool Smooth)
{
    for (unsigned int i = 0; i < Paths.size(); i++)
        if (Paths[i] == Path) return -1;

    sf::Texture* Texture = new (std::nothrow) sf::Texture;
        if (!Texture) return -2;

    sf::Sprite* Sprite = new (std::nothrow) sf::Sprite;
        if (!Sprite) return -3;

    if (!Texture->loadFromFile(Path))
    {
        delete Texture;
        delete Sprite;
        return -4;
    }

    Texture->setSmooth(Smooth);
    Sprite->setTexture(*Texture);

    Paths.push_back(Path);
    Textures.push_back(Texture);
    Sprites.push_back(Sprite);

    return Sprites.size() - 1;
}
 

And here is the destructor:

Phox::cSpriteManager::~cSpriteManager()
{
    std::cout << "SpriteManager: Calling Dtor.\n";
    for (unsigned int i = 1; i < Sprites.size(); i++)
        if (Sprites[i] != 0) delete Sprites[i];

    //for (unsigned int i = 1; i < Textures.size(); i++)
        //if (Textures[i] != 0) delete Textures[i];

    Textures.clear();
    Sprites.clear();
    Paths.clear();
    std::cout << "SpriteManager: Finished Dtor.\n";
}
 

Occasionally when main() ends and the above lines are not commented I get a 0xC0000005 segfault.. However commenting the lines never yields the error. The weird part about the error is that when it crashes I see both "Calling Dtor." and "Finished Dtor." which makes me believe that deleting the textures doesn't actually cause the segfault. Like I said though, commenting those two lines never ever crashes.

I'm using the latest SFML github source (2 days ago) and GCC 4.7.0. Any help in understanding the problem would be really appreciated. 

[eXpl0it3r]

Make use of gdb to find out what happens where exactly... The debugger is the programmers most valueable tool, if you don't how to use it, then learn it!

Next it isn't adviced to manually manage your resources (i.e. calling new and delete on your own), you should take a look at smart pointers like std::shared_ptr and keep the RAII ideom in mind.
Also 0 is not equal to NULL and it's adviced to use nullptr instead.

For the error I don't know what would cause it, but with the call backtrace and some debugging you could probably figure it out.

[Ruckamongus]

Alright, well I started learning how to use GDB and it wasn't the sf::Textures at all... It seems to actually be sf::Vertex. I think I'm using sf::RectangleShape improperly. This is a screenshot of my call stack when I get the segfault:

http://postimage.org/image/8pt4szacf/

It seems that GameInstance (within InstanceManager) is setting this whole thing off. GameInstance holds an sf::RectangleShape like this:

class GameInstance
{
     private:
          sf::RectangleShape DebugRect;
}
 

I don't understand what's going on, are shapes supposed to be allocated on the heap? Again, this is my first time using GDB so don't be too harsh


Also, a completely separate question: When using std::nothrow in C++11, does it still return 0 or does it return nullptr?

[eXpl0it3r]

Alright, well I started learning how to use GDB and it wasn't the sf::Textures at all... It seems to actually be sf::Vertex. I think I'm using sf::RectangleShape improperly. This is a screenshot of my call stack when I get the segfault:

http://postimage.org/image/8pt4szacf/

It seems that GameInstance (within InstanceManager) is setting this whole thing off. GameInstance holds an sf::RectangleShape like this:

The error does occure in the destructor of GameInstance. Without the code it's really hard to tell what the actual problem is. It seems like you're doing something quite wrong.

Also, a completely separate question: When using std::nothrow in C++11, does it still return 0 or does it return nullptr?

As the one online C++ reference tells us, it uses nullptr. The question is more, why in the world would you want to use that? I don't know much about it, since I've never used it, but the answers on the one Stackoverflow question are quite similar and state that you don't really need it.

[Ruckamongus]

I use nothrow because I haven't learned to use exceptions and nothrow is a lazy/cheap way of checking for an error without checking for an exception. The destructor of GameInstance is created by the compiler, would it help to see the header for GameInstance? By the way, GameInstance does inherit from two other classes... could this be the problem?

Also, thanks for showing me that link from C++ reference. I normally try to find my answers from www.cplusplus.com.

[eXpl0it3r]

I use nothrow because I haven't learned to use exceptions and nothrow is a lazy/cheap way of checking for an error without checking for an exception. The destructor of GameInstance is created by the compiler, would it help to see the header for GameInstance? By the way, GameInstance does inherit from two other classes... could this be the problem?

None of that will really help, maybe get a step closer to the problem, but what you actually have to do is a minimal (i.e. as less lines of code as possible that still produces the error) but complete (i.e. one can take your code and compile it) example. Often in the task of trimming down things, one finds the mistake on yourself.

Also, thanks for showing me that link from C++ reference. I normally try to find my answers from www.cplusplus.com.

Unfortunatly cplusplus.com isn't uptodate with the whole C++11 standard. They got a few but not very much of these functions. Cppreference is a wiki and thus gives the people more power to change things.

[Ruckamongus]

None of that will really help, maybe get a step closer to the problem, but what you actually have to do is a minimal (i.e. as less lines of code as possible that still produces the error) but complete (i.e. one can take your code and compile it) example. Often in the task of trimming down things, one finds the mistake on yourself.

Okay, I'm wondering if it has something to do with the inheritance now... I just can't figure it out. GameInstance and it's two base classes have nothing allocated to the heap so I can't figure out what could be going wrong. I'll dig more and see if I can come up with something. I am not 100% sure that I'm using virtual functions and destructors properly either, do you think this could potentially be the problem?

Unfortunatly cplusplus.com isn't uptodate with the whole C++11 standard. They got a few but not very much of these functions. Cppreference is a wiki and thus gives the people more power to change things.

Yeah, I've noticed that. They do seem to be lacking a lot with the new standard. I'll definitely be digging around that wiki!




Edit:
One of my base classes had a virtual destructor while the other didn't. However giving them both a virtual destructor yields the same results; some undefined access violation it seems.