My std::vector just won't free memory (of the textures etc.)

[Brix2Brix]

Hi forum!
So I use a class named 'planet_system' for game levels and put the current one in a std::vector <planet_system>. planet_system consistes of, among other things, sprites and textures. To load the next level I clear the vector and load a new planet_system to put in to the vector. But every time this happens the memory just keeps rising as if the vector is not cleared but extended.
I have tried a lot of methods to free the memory of this vector like

        vecplanetsystems.clear();
        vecplanetsystems.shrink_to_fit();

or

        vecplanetsystems = std::vector <planet_system> ();

but nothing changes.
Then I had the idea that maybe the sprites and textures of the SFML library are not succesfully deleted by these methods (?) but im not sure.

I hope you can help me.
Thanks in advance,
 Brix2Brix

Edit:
My OS: Windows 7 64Bit
SFML version: 2.3.1
Compiler: Visual Studio 2015
Compiling for Windows x68

[AlexAUT]

See here.

We need a complete and working example to help you identify your problem. Otherwise we can only guess and it will delay the whole process to help you. Just try a simple main where you fill a vector and clear it, and post the code if the problem still occurs.



AlexAUT

[Brix2Brix]

@AlexAUT
Well, I basically already said everything of importance;

i have the class planet_system:

class planet_system
{
        public:
                planet_system(int intype, sf::Texture & texture_asteroid);
                void Render(sf::RenderWindow &window, sf::RenderTexture & rtex, int centerviewx, int centerviewy, sf::Vector2f viewsize, sf::Texture tex);
                void RenderParalax(sf::RenderWindow &window, sf::RenderTexture & rtex, int centerviewx, int centerviewy);
                void Update();
                void UpdatePriceMarket();

                std::vector <cplanet> vecplanets;
                int anzahl_planets;

                std::vector <casteroidfield> vecasteroidfields;

                sf::Texture tex_back;
                sf::Sprite spr_back;

                sf::Texture tex_paralax1;
                sf::Sprite spr_paralax1;

                sf::Texture tex_paralax2;
                sf::Sprite spr_paralax2;

                float sizex;
                float sizey;

                int type;
                int id;
                std::string string_name;
};

and have this in the delceration of main:

std::vector <planet_system> vecplanetsystems;

and in the game loop i have this when the new level is loaded:

// Either this
vecplanetsystems = std::vector <planet_system> ();

//or this ( but both dont work)
vecplanetsystems.clear();
vecplanetsystems.shrink_to_fit();

planet_system newsystem1(system_crnt, texmngr.getRef("asteroid1"));
vecplanetsystems.push_back(newsystem1);

And the Memory just won't be freed.

(!) But even when I just have a simple main with a vector of integers, fill and clear it, it is the same problem.

[Satus]

(!) But even when I just have a simple main with a vector of integers, fill and clear it, it is the same problem.

So why don't you post the code of your main? Instead of posting a lot of code that we can not compile.

[Brix2Brix]

@Satus

It is not much more than this:

#include <iostream>

int main()
{
        std::vector <int> vector;
        for (long int i = 0; i < 800000; i++)
        {
                vector.push_back(12);
        }

        int cinbuffer;
        std::cin >> cinbuffer;

        vector.clear();

        std::cin >> cinbuffer;


        return 0;
}

(!) Although I just realised that it actually does free the memory when I also do
vector.shrink_to_fit();

But It doesn't work the same way in my game when I do the same thing, so my question is, if there are maybe problems with the textures inside planet_system etc which are not being freed.

[Satus]

But It doesn't work the same way in my game when I do the same thing, so my question is, if there are maybe problems with the textures inside planet_system etc which are not being freed.

Just post your code. That we can compile.

[eXpl0it3r]

You can read the C++ standard or the available online references and learn that clear does not deallocate reserved memory.

But until you can show that your code is not allocating something without freeing it, chances are quite big that it's an issue in your code.

[Brix2Brix]

@eXpl0it3r

I know that clear does not deallocate memory, that is why I also use shrink_to_fit which does (at least I hope).

I don't know why, but I can't recreate the problem with the needed bits of my code? I does always work, so there is either a memory problem with the vectors and textures within the vector or someplace else. I will continue the search.
Just to be sure: If there is a vector of class b in class a, and I deallocate the memory of a vector of class a, the vector of class b within this vector is also gone, is it not?

[Jesper Juhl]

Since we have no SSCCE to test I can only guess.
Are you perhaps heap allocating all or parts of what you store in the vector so that clearing it just frees up the space used for pointers to stuff, not stuff itself?
RAII and smart pointers are usually the pills needed to be swallowed to correct such problems - if I guess correctly of course.
How about we get a SSCCE so we can actually test rather than guess?
Also see this (it seems relevant): http://www.catb.org/esr/faqs/smart-questions.html

[Brix2Brix]

I just realised that the problem was in an entirely different class which was stored in it. So I fixed it.
There was a problem with pointers in this other class.

Thanks for your patient help (and sorry if my questions were a bit obscure  )

[Jesper Juhl]

Maybe you could do us all a favor and tell us what that error in that other class was?
Otherwise this thread ends on a bit of an anti-climax ;-)

[SpeCter]

Maybe you could do us all a favor and tell us what that error in that other class was?

Just a wild guess, but I think he heap allocated stuff and assumed a vector would call delete on all of them when cleared...

[Jesper Juhl]

I don't like guessing. I'd like to know. Even if yours is a good guess...

[Brix2Brix]

Well, there is the class asteroid in the class planet_system. asteroid had this to handle the texture:

class asteroid(sf::Texture & tex_asteroid)
{
    sf::Texture &texref = sf::Texture();
    //...
}

and this was in the Constructor of asteroid:

texref = tex_asteroid;

I don't know exactly why these pointers caused this kind of problem, but I changed it so that there were no texture opjects or pointers anymore in asteroid and my memory problem disappeared 

Because the asteroids were stored in an vector inside of planet_system, I could guesss, that maybe the clearing and shrin_to_fit-ing of the planet_system-vector did not affect the asteroid-vector inside it?

[Nexus]

Well, there is the class asteroid in the class planet_system. asteroid had this to handle the texture:

class asteroid(sf::Texture & tex_asteroid)
{
    sf::Texture &texref = sf::Texture();
    //...
}

That's not even remotely valid C++. That's exactly the problem Jesper mentioned: if you don't bother to describe exactly what you did, we have to make assumptions and guess.

So please come up with real code. If your original code is big, reduce it -- but make sure it's valid C++, complete and still reproduces your problem.

I don't know exactly why these pointers caused this kind of problem

I don't see a single pointer in your code. Again, express yourself clearly, to avoid being misunderstood.