Plan for Phil Carlisle
by Phil Carlisle · 07/11/2004 (1:47 am) · 3 comments
Ooooh man, dont you just HATE memory bugs!
This week on the AI product has been pretty slow for me. I only had a bit of time outside of work to get some code done, but unfortunately most of that was taken up with a memory stomp bug that was causing fatal crashes.
Now a fatal crash isnt too bad, if its predictable. But as is usual with memory bugs, this fatal crash was totally random, basically a by-product of writing to memory such that EVENTUALLY the program dies.
Finding those things is just like searching for a needle in a haystack, so you have to do some work to narrow things down.
For instance:
1) What code have you just worked on, that might be causing a memory leak
2) If you bypass that code, does the error still occur
3) If it DOES still occur, try and bypass different parts of the code until you find a situation where it doesnt occur. Then slowly add back in the other parts *and test as much as possible* one at a time.
4) Once you have the errors occurring, try and figure our a useful test case to reproduce it
5) Try altering some of the minor details of the test case, to see if they have any affect.
Etc etc.
One thing I am guilty of, is that I did quite a lot of code last weekend without testing it. Or rather, without soak-testing it (soak testing is where you setup a case where the code gets run constantly in a loop and you check for memory consumption and crashes).
In this case, the error would occur after an AIPlayer died in combat, so its a case that hasnt been reproducable until fairly recently. But thats no excuse.
Anyway, now I'm happy to say that I've fixed the error and DMBOT is finally functional.
What was the error?
Well, I've not figured it out 100%, I just figured a workaround. The error occcured when I had a SimObjectPtrm_Target variable in any of my "Action" classes.
Action classes are C++ code that perform a specific function of the AI, for instance, there are action classes for:
Stop
Move
Pickup
Animate
Patrol
RangedAttack
MeleeAttack
Flee
Etc.
Well, these are stored in a vector on the player, so that basically you can issue these "actions" as commands for the player to execute.
I'm not totally sure WHY the simobjectptr would have issues, but it is a reference counted pointer type, so I'm guessing that I was misusing it and the reference counting was getting mangled, thus the pointer became invalid and any subsequent use of it was destructive. Suffice to say, a quick re-code of those pointer usages (now stored on the player), worked to fix the bug.
So the motto of todays plan is:
Test often, test for as long as possible, test new code AND old. In fact, just test a lot!
This week on the AI product has been pretty slow for me. I only had a bit of time outside of work to get some code done, but unfortunately most of that was taken up with a memory stomp bug that was causing fatal crashes.
Now a fatal crash isnt too bad, if its predictable. But as is usual with memory bugs, this fatal crash was totally random, basically a by-product of writing to memory such that EVENTUALLY the program dies.
Finding those things is just like searching for a needle in a haystack, so you have to do some work to narrow things down.
For instance:
1) What code have you just worked on, that might be causing a memory leak
2) If you bypass that code, does the error still occur
3) If it DOES still occur, try and bypass different parts of the code until you find a situation where it doesnt occur. Then slowly add back in the other parts *and test as much as possible* one at a time.
4) Once you have the errors occurring, try and figure our a useful test case to reproduce it
5) Try altering some of the minor details of the test case, to see if they have any affect.
Etc etc.
One thing I am guilty of, is that I did quite a lot of code last weekend without testing it. Or rather, without soak-testing it (soak testing is where you setup a case where the code gets run constantly in a loop and you check for memory consumption and crashes).
In this case, the error would occur after an AIPlayer died in combat, so its a case that hasnt been reproducable until fairly recently. But thats no excuse.
Anyway, now I'm happy to say that I've fixed the error and DMBOT is finally functional.
What was the error?
Well, I've not figured it out 100%, I just figured a workaround. The error occcured when I had a SimObjectPtr
Action classes are C++ code that perform a specific function of the AI, for instance, there are action classes for:
Stop
Move
Pickup
Animate
Patrol
RangedAttack
MeleeAttack
Flee
Etc.
Well, these are stored in a vector on the player, so that basically you can issue these "actions" as commands for the player to execute.
I'm not totally sure WHY the simobjectptr would have issues, but it is a reference counted pointer type, so I'm guessing that I was misusing it and the reference counting was getting mangled, thus the pointer became invalid and any subsequent use of it was destructive. Suffice to say, a quick re-code of those pointer usages (now stored on the player), worked to fix the bug.
So the motto of todays plan is:
Test often, test for as long as possible, test new code AND old. In fact, just test a lot!
About the author
#2
. In the end I converted the ref counted pointers to standard pointers and this caused the program to crash reproducably and I was able to track down the issue.
Purify is a great tool, It's hard to justify an $800 tool that you only use once or twice a project, but in those times it catches some REALLY nasty bugs that would take years to find otherwise...
07/11/2004 (8:24 am)
I had a simmilar problem with the boost libraries (www.boost.org) auto_ptr, instances of my CTileAction class were stored in a vector of auto_ptrPurify is a great tool, It's hard to justify an $800 tool that you only use once or twice a project, but in those times it catches some REALLY nasty bugs that would take years to find otherwise...
#3
07/11/2004 (2:29 pm)
Yeah, Ive used purify myself before. But in this case, I hadnt got quite THAT desperate (to get the demo etc). 
Torque Owner Rodney Jacks
There are some very good tools for finding memory leaks and memory corruption. The best is Rational Software's Purify. Although pricey ($800 for the Windows version) it is really worth the money and very easy to use. They also have a trial version that you can use to determine how well it works. We have a copy where I work and it has saved us many times. In fact, it is part of our regression testing.
Best Regards,
Rodney