Bad_alloc

[jrabasco]

Something provokes some std::bad_alloc while in the level. One must search the web to find out what's happening.

DUE TO MEMORY LEAK IN LEVEL !!!!! TRACK IT AND KILL IT !!!!

[Protectator]

Found this -> http://stackoverflow.com/questions/9456728/how-to-deal-with-bad-alloc-in-c

And it says :

In general you cannot and should not try to respond to this error. bad_alloc indicates that a resource cannot be allocated because not enough memory is available. In most scenarios your program cannot hope to cope with that, and terminating soon is the only meaningful behaviour.

[Protectator]

To me, it means there are memory leaks in the code.

[jrabasco]

I tested it on my computer : we have a huge memory leak in the level, it went up to more than 1.5GB of memory usage before crashing.

[Protectator]

Can confirm, just tested the exact same thing :

[jrabasco]

So let's track this leak and cancel it !

[Protectator]

Note that it only happens when we're in a level. The memory doesn't go up at main menu or on the overworld.

[jrabasco]

Yep there is just a huge memory leak in the Level (thousands of KB are lost each second)

[Gerardufoin]

Damn, I didn't want to discuss about the game (I have work, fu), but I'll give you a clue: Did you check the move of Elodie, as I asked you yesterday ? If the second move is called, there is a 'new' who isn't delete each time. (Don't know if this is it, but no one seems to care about that anyway)

[jrabasco]

I'll check it tonight

[BinaryBrain]

Apparently, it has nothing to do with tiles (since a little level or a big level don't change anything). I think this is on Elodie.

[jrabasco]

It is not on the doStuff method, it is possibly in the Game

[jrabasco]

The major part of the leak has been repaired, but still some KB, are leaking, currently working on it.

The problem was the Console.cpp doing loads of new that were never freed, solution was to have an array of sf::Text and just updating them instead of creating new ones. Thanks Gerardufoin for the fix.

[jrabasco]

Hitbox move created a new sf::Vector2f which leaded to continuous loss of memory, fixed by Gerardufoin.

The destructor of "Level" was not properly implemented, it did not delete anything (maybe the person who wrote the class because of the two typedef : typedef std::vector< std::vector<TileSprite> > TileMap; and typedef std::map<std::string, Entity> EntityMap; which made the level look like owning no pointer but in fat it did). fixed by me.

There are still random losses (I did not manage to understand why, mainly because I loaded many times the level which caused some losses and then after loading it like 15 times I could reload it as many times as I wished (tried like 50 times) without no loss). We'll find them using an analyzer but basically the game can run for hours without running out of memory.