Beginning To Lose Marbles Over A Crashing Bug

[PokeParadox]

CromoZome Bleeding Edge Source

Basically I've been trying and trying to find this damned bug... I think it is in the collision routines, but I can't seem to get any coherent clues from the callstack and such.

Any help would be appreciated as this is obviously hindering my progress :S

 

[synkro]

We are not debugging your game for you. Just get us the troublesome functions.

 

[PokeParadox]

That was not my intention. I don't expect anyone to sit and debug this extensively. I was hoping that someone would skim over the code in StateMain.cpp and see if they can something I haven't.

 

[Mr.Jabberwocky]

What is the bug ? Can it be easily reproduced ?

 

[PokeParadox]

OK basically in the main game, the CromoZomes eat each other. And I think somehow I'm deleting too many CromoZomes, but I'm having trouble pinpointing it, but it seems to occur when there is a collision... it just seems to be quite random... and it just crashes out of the game completely when it happens.
The demo mode should let you reproduce the bug, but you'd have to leave it running for a while, it could happen quickly or ... well yeah I can't figure out what the cause is.
The debug mode is compiled with MemWatch so that should help track down any memory bugs... although I rewrote code to not use new and delete... just to see if it would help.
Any help on this would be greatly appreciated.

 

[Pickle]

OK basically in the main game, the CromoZomes eat each other. And I think somehow I'm deleting too many CromoZomes, but I'm having trouble pinpointing it, but it seems to occur when there is a collision... it just seems to be quite random... and it just crashes out of the game completely when it happens.
The demo mode should let you reproduce the bug, but you'd have to leave it running for a while, it could happen quickly or ... well yeah I can't figure out what the cause is.
The debug mode is compiled with MemWatch so that should help track down any memory bugs... although I rewrote code to not use new and delete... just to see if it would help.
Any help on this would be greatly appreciated.

maybe you could add some try and catch statements and add some break points if your doing a window debug.

 

[Mr.Jabberwocky]

The GP2X version cannot link flush_uppermem_cache and the PC builds cannot find sdl_gfx. Any suggestions ? I don't seem to have the files for memwatch.

 

[PokeParadox]

I've had the problem with "flush_uppermem_cache" since migrating to Linux... I can no longer get Code::Blocks to compile the ASM for the MMUHack... I just kept a copy of the .o file hanging around as a temporary workaround... it should be in the archive.
Alternatively you could comment out all references to the MMU hack...

As for SDL_gfx I'm not entirely sure why it can't find SDL_gfx... although I have a hunch that you should try linking SDLgfx instead of SDL_gfx... or something along those lines... I remember having to do something like that when I migrated.

memwatch can be found here.

 

[Squidge]

Reading someone elses code to find out how it works isn't exactly easy. Debugging someone else code is even harder. We have no idea how your code is supposed to work, how you designed it or what you were thinking when your wrote it.

I suppose you could say it's similar to saying something like "I've built my own TV, but it doesn't work, whats wrong?".

As a bare minimum, you should describe what your code does, and how it does it, with a description of what every file is for, with particular emphasis on the part that doesn't work correctly (describe the part of the code that seems to fail, and explain why you wrote it how you did). It's very difficult to debug something if you don't know how it is supposed to work in the first place.

 

[PokeParadox]

That does make some sense, sorry about that. I have tried to keep the code commented though...

In any case I have to head out to work very soonish but I will post later an insight of what is (supposed to be) going on.

 

[Parkydr]

A quick valgrind on the PC version says

CODE

Invalid read of size 4
==7930== at 0x8057A59: Node::getPos() (Node.h:156)
==7930== by 0x80613F0: StateMain:rocessCollisionLists() (StateMain.cpp:928)
==7930== by 0x8061F26: StateMain::update() (StateMain.cpp:441)
==7930== by 0x804C7A7: Engine::stateLoop() (Engine.cpp:131)
==7930== by 0x8052E10: main (_main.cpp:18)
==7930== Address 0x4B2A02C is 12 bytes inside a block of size 160 free'd
==7930== at 0x4024096: operator delete(void*) (vg_replace_malloc.c:244)
==7930== by 0x80586EA: __gnu_cxx::new_allocator<Node>::deallocate(Node*, unsigned) (new_allocator.h:97)
==7930== by 0x8058714: std::_Vector_base<Node, std::allocator<Node> >::_M_deallocate(Node*, unsigned) (stl_vector.h:134)
==7930== by 0x8058ABF: std::_Vector_base<Node, std::allocator<Node> >::~_Vector_base() (stl_vector.h:120)
==7930== by 0x8058B28: std::vector<Node, std::allocator<Node> >::~vector() (stl_vector.h:268)
==7930== by 0x806DA06: Snake::~Snake() (Snake.h:16)
==7930== by 0x806DC28: __gnu_cxx::new_allocator<Snake>::destroy(Snake*) (new_allocator.h:110)
==7930== by 0x806E2D8: std::vector<Snake, std::allocator<Snake> >::erase(__gnu_cxx::__normal_iterator<Snake*, std::vector<Snake, std::allocator<Snake> > >) (vector.tcc:114)
==7930== by 0x8061361: StateMain:rocessCollisionLists() (StateMain.cpp:922)
==7930== by 0x8061F26: StateMain::update() (StateMain.cpp:441)
==7930== by 0x804C7A7: Engine::stateLoop() (Engine.cpp:131)
==7930== by 0x8052E10: main (_main.cpp:18)



In StateMain:rocessCollisionLists() line 922 you do

CODE

snakes.erase(snakes.begin() + collisionLists[k]);



But then do a lot of other stuff with snakes[collisionLists[k]] after.

Could be your bug, but in any case it's bad code.

 

[PokeParadox]

Ah! Crap I can't believe I missed that! >_>
Yes that's very likely the cause of the crash. Thanks so much dude!
Your name will be added to the credits, ha ha ^_^

That call list is more detailed than the one that gets spit out here...

Anyway, I really can't say how grateful I am since I've been searching for the bug for weeks... :lol:

EDIT: Well I think that was it! Another release is due in the next few days I think

 

[Parkydr]

Valgrind is very good any memory bugs, you have to use x86 Linux to use it though

 

[Sphinxter]

Reading someone elses code to find out how it works isn't exactly easy. Debugging someone else code is even harder. We have no idea how your code is supposed to work, how you designed it or what you were thinking when your wrote it.

I suppose you could say it's similar to saying something like "I've built my own TV, but it doesn't work, whats wrong?".

As a bare minimum, you should describe what your code does, and how it does it, with a description of what every file is for, with particular emphasis on the part that doesn't work correctly (describe the part of the code that seems to fail, and explain why you wrote it how you did). It's very difficult to debug something if you don't know how it is supposed to work in the first place.

Amen to that. A frightening amount of people take to the sky and start coding away without ever filing a flight plan. Flow charts can convey so much.

 

[Parkydr]

Often you don't need to know much about the code - I still don't know any of the details of Cromozone

I don't know much about 90% of the stuff I've ported, usually just the 10% I've had to change. A bug should be obvious - a crash or something that doesn't look right, if it isn't then it probably doesn't matter.

You only really need to understand code when when you want to refactor it and so make the code better, not just fix it.

 

[Squidge]

Often you don't need to know much about the code - I still don't know any of the details of Cromozone

That's because you've not really looked at the code, you've run it through a memory tester and looked at the line of code it spit out as being faulty. Could you have done that as quick without using Valgrind just by looking at the code?

QUOTE
You only really need to understand code when when you want to refactor it and so make the code better, not just fix it.


Ok, say we take an emulator where a sprite occasionally disappears incorrectly at random intervals in a certain game. How would you go about fixing it without understanding how it works?

 

[Pickle]

QUOTE
You only really need to understand code when when you want to refactor it and so make the code better, not just fix it.

Ok, say we take an emulator where a sprite occasionally disappears incorrectly at random intervals in a certain game. How would you go about fixing it without understanding how it works?



That's any easy one, ask you to do it.

 

[Parkydr]

Often you don't need to know much about the code - I still don't know any of the details of Cromozone

That's because you've not really looked at the code, you've run it through a memory tester and looked at the line of code it spit out as being faulty. Could you have done that as quick without using Valgrind just by looking at the code?


No - that's why I used valgrind and that was my point, I didn't have to understand the code.

If I looked through the code, I may have spotted the erase, I still may not have understood how the collision detection works. It's like when you spot "if (i = 0)" and realise it it should be "==". Tools like static analysers are good at spotting stuff like that. If there's a tool why not use it.

QUOTE

QUOTE
You only really need to understand code when when you want to refactor it and so make the code better, not just fix it.


Ok, say we take an emulator where a sprite occasionally disappears incorrectly at random intervals in a certain game. How would you go about fixing it without understanding how it works?


I would look at the code drawing the sprite, so yes I would have to understand part of the code. It may be that it disappears when a certain variable goes negative and I put in a bit of code to set it back to zero in this case, which fixes it.

I see a lot of this in my job in the maintenance phase of projects, often it's the symptoms that are fixed not the cause (which does require understanding).

I think we're using different criteria for "understand". You may have to understand how bits of the program work, just not the whole thing.

 

[Squidge]

Yes, I agree with that. You have to understand how the portion of code works that is faulty.

If Valgrind didn't work, you would only have "I think I have a bug in my colision routines" to work on. You would have no idea what routines/files did the colision, so you would need that information (plus what they supposed to do compared to what they were actually doing), which was basically what I was trying to say to PokeParadox.

 

[PokeParadox]

Well I am using x86 linux, so I'll have to look into valgrind... like I said, the call stack didn't reveal much to me...

I think that was the bug, so far so good in any case.

And I did say that the collisions routines were in StateMain.cpp ... but in any case I'm so happy I can just get on with things with that bug squashed, thanks again