NULL == 0xbf800000 ?
by Eric Hartman · in Torque Game Engine · 06/23/2005 (2:04 am) · 4 replies
Heres the situation:
I'm working on my game, Blockland. It involves building with lego-like bricks.
I have created a new SceneObject child class and datablock combination to represent the bricks. In the datablock I need to store 3 arrays of booleans. Since the size of the arrays can be as low as 1 or as high as 7k, I'm using a dynamically allocated array.
-All 3 array pointers are initialized to NULL in the constructor
-All 3 arrays are allocated in the same place (the ::preload function) with exactly the same statement
-The arrays are only referenced in about 8 places. I've checked them all
Now the problem:
Of course, I want to delete [] these dynamic arrays in the destructor. And before I delete [] them, I check to make sure they aren't NULL.
About 1 in every 5 times that I run the program, it will crash during the "Loading Datablocks" phase with the assert
"Not an allocated block!"
As far as I can tell, the SimDataBlockEvent creates a temporary datablock object and then deletes it without preloading it. This should be fine, because I initialized the 3 array pointers to NULL, so it wont try to delete them if they aren't allocated.
BUT, it crashes because one of the 3 array pointers is 0xbf800000 instead of NULL.
I have absolutely no idea what is happening. The other 2 arrays are 0x00000000 like they should be. If there was an error in my code, it should happen every time, right? It seems like sometimes it decides to change NULL to 0xbf800000 for no reason.
I'm working on my game, Blockland. It involves building with lego-like bricks.
I have created a new SceneObject child class and datablock combination to represent the bricks. In the datablock I need to store 3 arrays of booleans. Since the size of the arrays can be as low as 1 or as high as 7k, I'm using a dynamically allocated array.
-All 3 array pointers are initialized to NULL in the constructor
-All 3 arrays are allocated in the same place (the ::preload function) with exactly the same statement
-The arrays are only referenced in about 8 places. I've checked them all
Now the problem:
Of course, I want to delete [] these dynamic arrays in the destructor. And before I delete [] them, I check to make sure they aren't NULL.
About 1 in every 5 times that I run the program, it will crash during the "Loading Datablocks" phase with the assert
"Not an allocated block!"
As far as I can tell, the SimDataBlockEvent creates a temporary datablock object and then deletes it without preloading it. This should be fine, because I initialized the 3 array pointers to NULL, so it wont try to delete them if they aren't allocated.
BUT, it crashes because one of the 3 array pointers is 0xbf800000 instead of NULL.
I have absolutely no idea what is happening. The other 2 arrays are 0x00000000 like they should be. If there was an error in my code, it should happen every time, right? It seems like sometimes it decides to change NULL to 0xbf800000 for no reason.
About the author
#2
Now I'm getting the same problem, just in a different place.
ShapeBaseData::packData() crashes on this piece of code here:
06/23/2005 (2:20 pm)
I went into platformMemory.cc and uncommented #define DEBUG_GUARD (is there more to it than that?)Now I'm getting the same problem, just in a different place.
ShapeBaseData::packData() crashes on this piece of code here:
if( stream->writeFlag( debris != NULL ) )
{
stream->writeRangedU32(packed? SimObjectId(debris):
debris->getId(),DataBlockObjectIdFirst,DataBlockObjectIdLast);
}because debris is 0xbf80000 instead of 0x00000000 like it should be.
#3
You're probably being bitten by an uninitialized pointer somewhere (possibly in someone else's code). I recommend you write a little debug function to "ensure nullness" and sprinkle it liberally throughout your code. Isolating where the tromping (intermittently) occurs will Help Alot.
EDIT: Something like
With this you can check all the places in your arrays that shouldn't have nulls, while ignoring valid portions of your arrays.
This won't do your efficiency any favors, but that's not really an issue at this point.
--Mark
06/23/2005 (2:40 pm)
Sounds like your memory is stepping on its own toes. Or at least SOMETHING is writing where it Should Not.You're probably being bitten by an uninitialized pointer somewhere (possibly in someone else's code). I recommend you write a little debug function to "ensure nullness" and sprinkle it liberally throughout your code. Isolating where the tromping (intermittently) occurs will Help Alot.
EDIT: Something like
#define DEBUG_CHECK(array, begin, len) \
for( int unusedName = begin; unusedName < begin + len; ++unusedName ) \
ASSERT( array[unusedName ] == NULL);With this you can check all the places in your arrays that shouldn't have nulls, while ignoring valid portions of your arrays.
This won't do your efficiency any favors, but that's not really an issue at this point.
--Mark
#4
06/24/2005 (9:08 am)
I think i found the problem. In one particular case I had hardcoded a loop assuming that there would always be 5 elements in one particular array, but sometimes there are only 4. And I put the loop way at the bottom instead of in the section where it should be so I didn't catch it.
Associate Ben Garney