Pandora Pandora Panic

[SiegfriedCroes]

I've also noticed that the Arena mini-game is unfortunately memleaking a lot. I kind of knew that before since I was getting a lot of pointer related questions from Dragons_Slayer... but it's about 10MB each time the game loads... I'm going to try and see if Valgrind helps at all but I'm pretty sure you are doing some special things with pointers somewhere!

Yeah I know, Arena is one big memory leak at the moment, it's because I still can't figure out why it crashes with a segfault the moment I try to delete something...

 

[foxblock]

I've also noticed that the Arena mini-game is unfortunately memleaking a lot. I kind of knew that before since I was getting a lot of pointer related questions from Dragons_Slayer... but it's about 10MB each time the game loads... I'm going to try and see if Valgrind helps at all but I'm pretty sure you are doing some special things with pointers somewhere!

Yeah I know, Arena is one big memory leak at the moment, it's because I still can't figure out why it crashes with a segfault the moment I try to delete something...

Well, I had a look at it and here are the results:
I reduced the memory leak by 5MB by deleting the hero and music at the end, but this leads to some random crashes in-game (very strange).
When I try to delete the units, too, the game always hangs/crashes. But the strange part is that it crashes when trying to delete the hero, which worked before (if I delete that line it crashes on deleting the units).
Here are the trackbacks:

It seems to hang on some SDL function calls and I doubt the Arena game code is solely responsible for this (as for example the destructor of the Hero is empty), but I might be wrong here and will have a closer look at this...

foxblock out

 

[SiegfriedCroes]

yeah it's very weird, I tried some debugging with cout's a while ago, I tried deleting the hero and I came to the conclusion it crashes when all the code in the destructor of the hero is executed (I put a cout at the end and it appeared in the stdout.txt) but before the actual "delete m_HeroPtr;" line as the cout that I put after that one isn't in the stdout... Most of the time it crashes in SDL_SetTimer but I just tried it again and now it's in SDL_SetGamma... By the way, I always do these tests with the debugger, when do "build and run" it just runs fine.

 

[PokeParadox]

It's random pointer errors. The problem is a stray pointer is pointing to wrong code and that's why it looks like random library functions are crashing. I will try and carefully tidy up the pointer and run it through Valgrind and hopefully get it working nicely. Might be after the weekend though.

 

[mduffor]

yeah it's very weird, I tried some debugging with cout's a while ago, I tried deleting the hero and I came to the conclusion it crashes when all the code in the destructor of the hero is executed (I put a cout at the end and it appeared in the stdout.txt) but before the actual "delete m_HeroPtr;" line as the cout that I put after that one isn't in the stdout... Most of the time it crashes in SDL_SetTimer but I just tried it again and now it's in SDL_SetGamma... By the way, I always do these tests with the debugger, when do "build and run" it just runs fine.

Errors like that are generally because either you have variables you have not initialized, or you are writing outside of your allocated memory on the stack and trashing other variables. Do you have your compiler set to output every warning possible? Your code should compile cleanly without a single warning when warnings are set to the max. Also make sure in every constructor (if using C++) that you initialize every member variable to some default value, and look out for copy constructors (especially default copy constructors) since the default copy constructor just copies the memory, and you can wind up with two pointers to the same dynamically allocated memory (for classes that dynamically allocate memory of course). When you free the first instance you may be freeing the allocated memory, but the copy still points to the now deallocated memory but doesn't realize it.

Just some random advice from my own experiences with tracking down random memory glitches in games. Hope it helps.

Cheers!

 

[foxblock]

Well, I don't have Linux so I can't run Valgrind which probably is much more effective than just trying things randomly
Another note: Depending on how or what I delete the game does not crash when selected in the level selector the first time but the second time... very strange

Anyway, good luck on fixing that

foxblock out

 

[Vorporeal]

I'll try taking a look later today - it's been a while since I've done some serious bug hunting, and now seems like a good time to start practicing.

Also, it seems (from your first picture) that there's a problem freeing the actual SDL_Surface that holds the image data for the AnimatedSprite (the SDL_Surface within the Image class in the AnimatedSprite). Make sure that you're freeing an SDL_Surface* and not just an SDL_Surface.

 

[foxblock]

Also, it seems (from your first picture) that there's a problem freeing the actual SDL_Surface that holds the image data for the AnimatedSprite (the SDL_Surface within the Image class in the AnimatedSprite). Make sure that you're freeing an SDL_Surface* and not just an SDL_Surface.

I doubt this is the problem as that code belongs to the Penjin framework and it works in other games, too.
As far as I understand PokeParadox the problem are the pointers in the Arena game which are not handled correctly and lead to a wrong memory adress at the end, so wrong stuff gets freed (and some other probably not) which leads to errors in the SDL functions (as they try to address memory which got freed by mistake).

 

[SiegfriedCroes]

The thing that makes this all so weird is that I have always used pointers in my games I made at school (with a different Win32 based engine) and I have never got this kind of problems... about that default copy constructor, I know that we at school always disable it with a line of code but I already tried putting those in the Arena code but it didn't work. But know that I think of something, could those crashes have anything to do with the fact that I used functions like render(SDL_Surface* screen) and userInput(SimpleJoy* input), Most of the minigames now use just render() and userInput()...

 

[foxblock]

The thing that makes this all so weird is that I have always used pointers in my games I made at school (with a different Win32 based engine) and I have never got this kind of problems... about that default copy constructor, I know that we at school always disable it with a line of code but I already tried putting those in the Arena code but it didn't work. But know that I think of something, could those crashes have anything to do with the fact that I used functions like render(SDL_Surface* screen) and userInput(SimpleJoy* input), Most of the minigames now use just render() and userInput()...

I never use render(), but render(SDL_Surface* screen) and it works fine, but this seems to depend on what engine it is using (SDL or OpenGL):

#ifdef PENJIN_SDL
 void StateMain::render(SDL_Surface *screen)
 {
   player->render(screen);
 }
 #else
 void StateMain::render()
 {
   player->render();
 }
 #endif

 

[scibotic]

Artist here, what do you guys need done?

[Edit] Too late, got deadlines to deal with.

 

[PokeParadox]

The thing that makes this all so weird is that I have always used pointers in my games I made at school (with a different Win32 based engine) and I have never got this kind of problems... about that default copy constructor, I know that we at school always disable it with a line of code but I already tried putting those in the Arena code but it didn't work. But know that I think of something, could those crashes have anything to do with the fact that I used functions like render(SDL_Surface* screen) and userInput(SimpleJoy* input), Most of the minigames now use just render() and userInput()...

I never use render(), but render(SDL_Surface* screen) and it works fine, but this seems to depend on what engine it is using (SDL or OpenGL):

#ifdef PENJIN_SDL
   void StateMain::render(SDL_Surface *screen)
   {
     player->render(screen);
   }
   #else
   void StateMain::render()
   {
     player->render();
   }
   #endif

Both of those cases are fine just as long you are not trying to delete those pointers. I setup and tidy the SimpleJoy pointer at the beginning and end of execution so you should not delete it. Likewise SDL handles the main screen surface so don't try and delete that either.
There may be something funky going on with a copy constructor somewhere. Yes I should put guards against... and no I haven't as yet. I will take a look at it like I said but looks like after the weekend since I need to sleeeeep.

PS: About the two different render() functions: for PandoraPanic! we need to supply the "SDL_Surface* screen" to the render function since the preview images are generated this way. This is the only reason why you need to specificy the SDL_Surface* Penjin code that doesn't do anything fancy like this can just share the same render function as long as there is only Penjin code and classes contained within.

 

[Pickle]

The thing that makes this all so weird is that I have always used pointers in my games I made at school (with a different Win32 based engine) and I have never got this kind of problems... about that default copy constructor, I know that we at school always disable it with a line of code but I already tried putting those in the Arena code but it didn't work. But know that I think of something, could those crashes have anything to do with the fact that I used functions like render(SDL_Surface* screen) and userInput(SimpleJoy* input), Most of the minigames now use just render() and userInput()...

Is it just me or do you never delete the the pointers that you created. I did a search on one and there so no place where you use delete.

 

[foxblock]

The thing that makes this all so weird is that I have always used pointers in my games I made at school (with a different Win32 based engine) and I have never got this kind of problems... about that default copy constructor, I know that we at school always disable it with a line of code but I already tried putting those in the Arena code but it didn't work. But know that I think of something, could those crashes have anything to do with the fact that I used functions like render(SDL_Surface* screen) and userInput(SimpleJoy* input), Most of the minigames now use just render() and userInput()...

Is it just me or do you never delete the the pointers that you created. I did a search on one and there so no place where you use delete.

That's right and the reason why there is a 10MB memleak.
But as we said before, trying to delete the pointers he creates causes immediate or random in-game crashes...
Anyway, let's not talk about this anymore until someone looked over this with Valgrind as I don't see much sense in just guessing where the error might be.

 

[SiegfriedCroes]

I could have something to do with the following lines of code, at school we learned to use them by default and only change it if you know what you're doing:

// -------------------------
// Disabling default copy constructor and default 
// assignment operator.
// -------------------------

ClassName(const ClassName& ClassNameRef);									
ClassName& operator=(const ClassName& ClassNameRef);

with ClassName being the name of the class you put the code in. It could have something to do with this as this is the only difference between the code made in my school's engine and Penjin.

 

[Pickle]

The thing that makes this all so weird is that I have always used pointers in my games I made at school (with a different Win32 based engine) and I have never got this kind of problems... about that default copy constructor, I know that we at school always disable it with a line of code but I already tried putting those in the Arena code but it didn't work. But know that I think of something, could those crashes have anything to do with the fact that I used functions like render(SDL_Surface* screen) and userInput(SimpleJoy* input), Most of the minigames now use just render() and userInput()...

Is it just me or do you never delete the the pointers that you created. I did a search on one and there so no place where you use delete.

That's right and the reason why there is a 10MB memleak.
But as we said before, trying to delete the pointers he creates causes immediate or random in-game crashes...
Anyway, let's not talk about this anymore until someone looked over this with Valgrind as I don't see much sense in just guessing where the error might be.

Seems kind of backwards way to fix it (not the valgrind idea, but removing the deletes). Where were the deletes before? I would hope they would all be in the destrcutor of the arenastate. But if this was the case it doesnt make sense that there would be crashes during the running of the game since the deletes/deconstructors would only be run last.

 

[SiegfriedCroes]

Seems kind of backwards way to fix it (not the valgrind idea, but removing the deletes). Where were the deletes before? I would hope they would all be in the destrcutor of the arenastate. But if this was the case it doesnt make sense that there would be crashes during the running of the game since the deletes/deconstructors would only be run last.

there are no deletes at the moment as they have always caused crashes that's why it works but with memory leaks. If I try deleting something it is in the Destructor of the ArenaState, and although it doesn't really make sense, the moment that you enter the Selection box, he first construct the state, then do its init maybe he also renders it and then it gets deleted again (I saw this in the stdout.txt when doing couts, and I think this is just how the preview thing works...?) that's why it crashes as soon as you enter the selection box... there are some things that are deleted, the moment you hit a monster (which is also a pointer) it gets deleted with delete but this also crashes when doing just delete, but it worked like this:

m_MonsterArr[position] = new ArenaMonster();
delete m_MonsterArr[position];
m_MonsterArr[position] = 0;

It's really weird as this class (the MonsterList, that contains a Monster array and some functions for adding and deleting them) is completely the same as one I used for a game in my school's engine where it worked perfectly. So the crashes must have something to do with the way that Penjin works as I'm sure I'm not doing anything wrong in terms of C++ coding...

 

[Pickle]

Seems kind of backwards way to fix it (not the valgrind idea, but removing the deletes). Where were the deletes before? I would hope they would all be in the destrcutor of the arenastate. But if this was the case it doesnt make sense that there would be crashes during the running of the game since the deletes/deconstructors would only be run last.

there are no deletes at the moment as they have always caused crashes that's why it works but with memory leaks. If I try deleting something it is in the Destructor of the ArenaState, and although it doesn't really make sense, the moment that you enter the Selection box, he first construct the state, then do its init maybe he also renders it and then it gets deleted again (I saw this in the stdout.txt when doing couts, and I think this is just how the preview thing works...?) that's why it crashes as soon as you enter the selection box... there are some things that are deleted, the moment you hit a monster (which is also a pointer) it gets deleted with delete but this also crashes when doing just delete, but it worked like this:

m_MonsterArr[position] = new ArenaMonster();
 delete m_MonsterArr[position];
 m_MonsterArr[position] = 0;

It's really weird as this class (the MonsterList, that contains a Monster array and some functions for adding and deleting them) is completely the same as one I used for a game in my school's engine where it worked perfectly. So the crashes must have something to do with the way that Penjin works as I'm sure I'm not doing anything wrong in terms of C++ coding...

What your saying makes sense. I would move all (or as many as possible) contruction of objects out of init and into the state construtor and then delete them within the state decontructor. If you have to create something outside of the constructor, then you should be releasing it you right before you return the pass/fail state back to penjin.

 

[Vorporeal]

It might be easier to just do:

typedef std::list<ArenaMonster *> MonsterList;
typedef std::list<ArenaMonster *>::iterator MonsterListIter;

Using std::list would probably be easier (and "safer"?) than your own list code if you just want a simple list add to, iterate through, and delete from.

EDIT: Changed from ArenaMonster to ArenaMonster*.

 

[bzar]

It might be easier to just do:

typedef std::list<ArenaMonster> MonsterList;
typedef std::list<ArenaMonster>::iterator MonsterListIter;

Using std::list would probably be easier (and "safer"?) than your own list code if you just want a simple list add to, iterate through, and delete from.

If he's disabled the classes' copy constructor by declaring it private, std::list won't work. You would still need to use pointers (std::list<ArenaMonster*>), because std::list initializes its values by copying them. I'd recommend using auto_ptr with the list. Then he could just clear the list on exit and the auto_ptr:s would handle the deletes.