[beta5 bug] T3D crashes when loading collada/DTS without geometry [fixed]
by Manoel Neto · in Torque 3D Professional · 09/01/2009 (12:25 pm) · 8 replies
Okay, this existed since beta1, but I never got around to truly test it. It's not truly a bug, but missing functionality.
When using .DAE only for animations, T3D crashes if they don't contain any geometry. This is a major shortcoming if you have tons of animations, because each individual DAE contains a copy of the character geometry which isn't used at all and just serves to eat disk space and RAM.
So far we are getting around it by using a dummy box instead of the actual model when exporting the animations (which drastically reduces the file sizes).
When using .DAE only for animations, T3D crashes if they don't contain any geometry. This is a major shortcoming if you have tons of animations, because each individual DAE contains a copy of the character geometry which isn't used at all and just serves to eat disk space and RAM.
So far we are getting around it by using a dummy box instead of the actual model when exporting the animations (which drastically reduces the file sizes).
About the author
Recent Threads
#2
It's quite obvious what the problem is: numMeshes is zero. No memory is allocated for the isMesh array and thus it crashes when trying to delete a null pointer.
09/03/2009 (9:54 am)
Applied the changes but it doesn't fix the issue. Still crashes. Here's the callstack:Quote:
SOCCER_DEBUG.dll!_free_dbg_nolock(void * pUserData=0x047155a0, int nBlockUse=1) Line 1371 + 0x3b bytes C++
SOCCER_DEBUG.dll!_free_dbg(void * pUserData=0x047155a0, int nBlockUse=1) Line 1258 + 0xd bytes C++
SOCCER_DEBUG.dll!operator delete(void * pUserData=0x047155a0) Line 54 + 0x10 bytes C++
SOCCER_DEBUG.dll!operator delete[](void * p=0x047155a0) Line 21 + 0x9 bytes C++
> SOCCER_DEBUG.dll!TSShape::disassembleShape() Line 1326 + 0x15 bytes C++
SOCCER_DEBUG.dll!TSShape::write(Stream * s=0x0011db14) Line 1382 C++
SOCCER_DEBUG.dll!loadColladaShape(const Torque::Path & path={...}) Line 504 C++
SOCCER_DEBUG.dll!Resource<TSShape>::create(const Torque::Path & path={...}) Line 2011 + 0x9 bytes C++
SOCCER_DEBUG.dll!ResourceBase::assignResource(void * resource=0x00000000) Line 84 + 0x11 bytes C++
SOCCER_DEBUG.dll!ResourceBase::assign(const ResourceBase & inResource={...}) Line 64 C++
SOCCER_DEBUG.dll!Resource<TSShape>::operator=(const ResourceBase & base={...}) Line 196 + 0x18 bytes C++
SOCCER_DEBUG.dll!TSShape::addSequence(const Torque::Path & path={...}, const String & fromSeq={...}, const String & name={...}, int startFrame=0, int endFrame=-1, int * totalFrames=0x00000000) Line 1054 + 0x58 bytes C++
SOCCER_DEBUG.dll!TSShapeConstructor::_onLoad(TSShape * shape=0x0434daa8) Line 224 + 0x56 bytes C++
It's quite obvious what the problem is: numMeshes is zero. No memory is allocated for the isMesh array and thus it crashes when trying to delete a null pointer.
#3
The meshes vector is empty, but some object says they have a mesh, causing an out-of-bounds access.
09/03/2009 (10:01 am)
Seems fixing that part in the code just moves the crash further.Quote:
SOCCER_DEBUG.dll!Platform::debugBreak() Line 17 C++
SOCCER_DEBUG.dll!Vector<TSMesh *>::operator[](unsigned int index=0) Line 652 C++
SOCCER_DEBUG.dll!Vector<TSMesh *>::operator[](int i=0) Line 117 + 0x18 bytes C++
> SOCCER_DEBUG.dll!TSShape::init() Line 473 + 0x18 bytes C++
SOCCER_DEBUG.dll!TSShape::read(Stream * s=0x00121638) Line 1743 C++
SOCCER_DEBUG.dll!loadColladaShape(const Torque::Path & path={...}) Line 416 + 0x12 bytes C++
SOCCER_DEBUG.dll!Resource<TSShape>::create(const Torque::Path & path={...}) Line 2014 + 0x9 bytes C++
The meshes vector is empty, but some object says they have a mesh, causing an out-of-bounds access.
#4
I placed a breakpoint inside the fix, it never triggers (the crash occurs way before it has the chance).
09/03/2009 (10:17 am)
Actually, the problem is more widespread. Somehow the shape has no meshes (numMeshes is zero) but the very first object tells it has a mesh, causing memory corruption, out of bounds accesses and whatnot.I placed a breakpoint inside the fix, it never triggers (the crash occurs way before it has the chance).
#5
09/03/2009 (10:25 am)
Seems the culprit is TSShape::createEmptyShape(). There it creates the first object entry:objects.set(dMalloc(1 * sizeof(Object)), 1); objects[0].nameIndex = 2; objects[0].numMeshes = 1; objects[0].startMeshIndex = 0; objects[0].nodeIndex = 0; objects[0].nextSibling = -1; objects[0].firstDecal = -1;
#6
09/03/2009 (10:31 am)
No deal. I got it to not crash... but it doesn't load any sequences off the file anymore.
#7
My bad => I missed part of the fix for this issue (there have been a lot of changes to that file since b5). I've updated the other thread with the required change. Basically, you don't want to call TSShape::createEmptyShape, since a) it creates an invalid shape that will crash when you try to save it (as you found), and b) it clears all the animations from the shape anyway!
09/03/2009 (7:24 pm)
Hi Manoel,My bad => I missed part of the fix for this issue (there have been a lot of changes to that file since b5). I've updated the other thread with the required change. Basically, you don't want to call TSShape::createEmptyShape, since a) it creates an invalid shape that will crash when you try to save it (as you found), and b) it clears all the animations from the shape anyway!
#8
09/04/2009 (10:05 am)
Ah, this explains why the changed code was never triggered. It works perfectly now, and my 571KB DAE animation turns into a beautiful 9KB DTS file.
Associate Chris Robertson
This is fixed in trunk => I've posted the code change here but haven't had confirmation that it fixes the issue in b5 as well.