Crash in deserialize

[SFCBias]

I created a command line tool to load a mesh create a collision and serialize it to file. Then in another program (on the same machine) when i attempt to load the file, it crashes in the dgTree::Find() function for some reason. When i tried to deserialize the file from the command line tool, it worked with no error, so i'm quite lost as to what the problem is. The command line tool and the game share source for deserialization. I'm running 64 bit linux with Newton 2.33

Code: Select all

void deserializeCollision(void* deserializeHandle,
        void* buffer, int size)
{
    assert((size % 4) == 0);
    fread(buffer, size, 1, (FILE*) deserializeHandle);
}

NewtonCollision* PhysicsManager::deserialize(const String& fileName)
{

    FILE* file = fopen(fileName.c_str(), "rb");
    if (!file)
   OGRE_EXCEPT(Exception::ERR_FILE_NOT_FOUND,"Cannot open Phyics file " + fileName,__PRETTY_FUNCTION__);

    NewtonCollision *collision = NewtonCreateCollisionFromSerialization(mWorld,
       &deserializeCollision, file);

    return collision;
}

[Julio Jerez]

maybe the path name

[SFCBias]

Well, it should have raised an exception if that were the case.

[SFCBias]

I'm still quite lost with this, not only do i have a guard so that if it can't find the file, it throws an exception, but I've even tried moving the file to the directory of the binary executable and still nothing. So why does it not work from program to program on the same system?

*EDIT: The collision pointer is a class member, when i deserialized from the initializer list in the c'tor, it crashed in a different place, in dgMemoryAllocator::Malloc

[Julio Jerez]

It does work from machine to machine as, it does not work if you serialize on an intel and try reading on power PC, but I asume you are do doing that.

[JernejL]

you aren't by any chance reading old versions of serialized files from win7/vista virtual store?

[SFCBias]

No I'm not even on a different machine yet. It's only between two programs which i wrote. It crashes on one but not the other which share the same serialize/deserialize code. I even tried reverting back to an older version of newton (2.31)

[Julio Jerez]

do not revert to older version, that will no acomplish anything.

has you try a simple collision shape like a Box, that way you can step in debug mode?

save a box in one machone, and make sure it loads, then try loading on teh secung machine, and if if fail you cna step trught teh code on both machine the code,
I never did that on Linix because I find Linux too hard to debug, but I did it on my win64 in 64 bit, and win 32 bot and the worked find. bit and.

that should bo be a complicated problem, people had being using seliazed assets since the engine was first released.

[SFCBias]

Im only using one machine right now. Thats what I find puzzling. All the important values of the library have been optimized out. I thought I fixed that but ill try recompiling the lib with debug info.

[SFCBias]

I've recompiled the library with the -g3 option to get the debug info and I found two things, 1st : In dgTree::Find() the address of m_head was a value like 0xbe9354e13df72a6a I bring this up, because i've never seen an address like this before, although it doesn't really raise any alarms. The next thing is that both the members of m_head (m_info and key) are NULL and 0 respectively . And also all the values of dgRedBackNode are NULL.

Based on what i've been debugging, it's not a problem with the collision itself, but in the Find function of dgTreeNode, In the program which serialized it, when it deserializes, the m_head node is NULL and all the guards for a NULL pointer are effective, but in the second program, m_head is some crazy value thats an invalid pointer, but not NULL and so it passes the guards but crashes when accessed.

[Julio Jerez]

dgTree is a read black tree, that is made long before HP made stl. I have being using for more than 20 years.
I can asure you there are not bug in any of teh contaiten classes.
you have to have a bug in the data itself.
like I say, save a simpel shape.

then in the shpe class you can set brak poit to see what if teh dat passed to teh callback in correct

for example say you use teh Box class,

the serialize function is this

Code: Select all

void dgCollisionBox::Serialize(dgSerialize callback, void* const userData) const
{
   dgVector size (m_size[0].Scale (dgFloat32 (2.0f)));
   size.m_w = m_destructionImpulse;

   SerializeLow(callback, userData);
   callback (userData, &size, sizeof (dgVector));
}

if you set a break point on that function you can see what the serialization is saving.
then on loading the deserialize function call this constructor.

Code: Select all

dgCollisionBox::dgCollisionBox(dgWorld* const world, dgDeserialize deserialization, void* const userData)
   :dgCollisionConvex (world, deserialization, userData)
{
   dgVector size;
   deserialization (userData, &size, sizeof (dgVector));
   m_destructionImpulse = size.m_w;
   Init (size.m_x, size.m_y, size.m_z);
}

se the break point there and verify that the data match.

[SFCBias]

There's the thing, the function NewtonCreateCollisionFromSerialization is crashing inside of dgTree::Find(). It's not even reaching the point where it creates the actual collision primitive. I tried with a box just to see, and same result...crash.

I must be missing _something_.

Code: Select all

template<class OBJECT, class KEY>
typename dgTree<OBJECT, KEY>::dgTreeNode* dgTree<OBJECT, KEY>::Find (KEY key) const
{
   if (m_head == NULL) {
      return NULL;
   }

   dgTreeNode* ptr = m_head;
   while (ptr != NULL) {
      CRASHES HERE ------> if (key < ptr->m_key) {
         _ASSERTE (CompareKeys (ptr->m_key, key) == -1) ;
         ptr = ptr->GetLeft();
      } else if (key > ptr->m_key) {
         _ASSERTE (CompareKeys (ptr->m_key, key) == 1) ;
         ptr = ptr->GetRight();
      } else {
         _ASSERTE (CompareKeys (ptr->m_key, key) == 0) ;
         break;
      }
   }
   return ptr;
}

I'm not sure how, but somehow the value of the pointer to m_head is getting a crazy, probably random, value and that messes up the entire process.

Here's the backtrace

Code: Select all

gdb/mi (9/7/11 4:07 PM) (Suspended)   
   Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.)   
      10 dgTree<dgCollision*, unsigned int>::Find() /home/bryce/Dev/newton-dynamics-2.33/coreLibrary_200/source/core/dgTree.h:411 0x00007ffff72858e1   
      9 dgWorld::CreateFromSerialization() /home/bryce/Dev/newton-dynamics-2.33/coreLibrary_200/source/physics/dgNarrowPhaseCollision.cpp:421 0x00007ffff727d89f   
      8 NewtonCreateCollisionFromSerialization() /home/bryce/Dev/newton-dynamics-2.33/coreLibrary_200/source/newton/Newton.cpp:4406 0x00007ffff73595e0   
      7 PhysicsManager::deserialize() /home/bryce/Dev/Pulse/Source/PhysicsManager.cpp:78 0x00000000004261ef   
      6 PhysicalObject::PhysicalObject() /home/bryce/Dev/Pulse/Source/PhysicalObject.cpp:19 0x00000000004257f1   
      5 PhysicsManager::createObject() /home/bryce/Dev/Pulse/Source/PhysicsManager.cpp:95 0x00000000004262e6   
      4 Character::Character() /home/bryce/Dev/Pulse/Source/Character.cpp:21 0x0000000000407514   
      3 Follower::Follower() /home/bryce/Dev/Pulse/Source/Follower.cpp:3 0x0000000000422896   
      2 CoreEngine::run() /home/bryce/Dev/Pulse/Source/CoreEngine.cpp:153 0x000000000040e13e   
      1 main() /home/bryce/Dev/Pulse/Source/main.cpp:36 0x0000000000427882   
   Thread [2] (Suspended)   


[Julio Jerez]

If it crashe with a Box as weel as with a collision tree, then teh bug is not in the dgTree.
Boxes do not use dgTree for anything at all.

like I said debug with a Box, it is a much simpler object to follow.
you can add traces to the functions I pointed before so that you can match what the serilation and deserialization is doing.

btw the root node in a redblack tree do changes each time the tree performe a rebalancin operation. afte insetion or deletion.
you cna set break pointe ther iof you want, but the will lead you anywhere

[SFCBias]

It's not creating anything from in deserialize. It reads the signatures then when it reaches this line

Code: Select all

dgBodyCollisionList::dgTreeNode* node = dgBodyCollisionList::Find (dgUnsigned32 (signature[1]));

The signatures are correct, but it crashes within this function.

[Julio Jerez]

if it crashes here dgBodyCollisionList::Find ()

Then what it means is the you have a bad pointer to the world file.
basically dgBodyCollisionList is a map the constain copies of object of a type time.
the funtion find only return a pointer to a node or NULL.
in not circuntance the function will crash unless the pointer to "this" is wrong.

your bug is that you are passing a wrong pointer to the newton world to the desirialization function.