Max DTS exporter crash in TSShapeInstance
by GuildHall SMU (#0009) · in Torque Game Engine · 08/26/2004 (1:34 pm) · 3 replies
Using the latest version of the HEAD (2004/08/25) I built a debug build of the Max DTS Exporter (for Max 5.1). While attempting to export a model, the exporter crashes at TSShapeInstance.cc line 320:
hShape is not initialized if the TSShapeInstance::TSShapeInstance(TSShape * _shape, bool loadMaterials) constructor is used, so this line results in a null pointer exception. hShape is used again at line 345:
Replacing both instances of hShape with mShape appears to fix the problem. I'm not familiar enough with the code to know if this is what was intended.
Stephen Hatcher
S32 colDetail = hShape->findDetail(buff);
hShape is not initialized if the TSShapeInstance::TSShapeInstance(TSShape * _shape, bool loadMaterials) constructor is used, so this line results in a null pointer exception. hShape is used again at line 345:
Con::errorf("%s.dts - Collision mesh names should start with Col or LOSCol, encountered '%s' in detail level %d", hShape->mSourceResource->path,mShape->names[mesh->object->nameIndex], dl);Replacing both instances of hShape with mShape appears to fix the problem. I'm not familiar enough with the code to know if this is what was intended.
Stephen Hatcher
#2
When the TSShape object is being explicitly managed it is assigned to hShape so that it will perform reference counting. mShape is set to point to hShape in this case so that all calls will pass through the managed code. When the resource is not explicitly managed, mShape points directly to the underlying object and hShape is unused since there is nothing to manage.
The only exception seems to be when hShape.getFilePath() is used to get the correct path to related assets, as this method is not available through mShape. It defaults to NULL if called on an unitialized hShape which is presumably what the code that uses it intends.
There probably should be some consistency between the naming conventions in tsShapeConstruct and tsShapeInstance since they each have hShape and mShape members, but mShape has a completly different type (StringTableEntry vs tsShape*).
Stephen
08/30/2004 (11:59 am)
The structure of the current code would seem to indicate that mShape should always be used rather than unifying them. hShape is a Resource (i.e. smart pointer), while mShape is a simple pointer. When the TSShape object is being explicitly managed it is assigned to hShape so that it will perform reference counting. mShape is set to point to hShape in this case so that all calls will pass through the managed code. When the resource is not explicitly managed, mShape points directly to the underlying object and hShape is unused since there is nothing to manage.
The only exception seems to be when hShape.getFilePath() is used to get the correct path to related assets, as this method is not available through mShape. It defaults to NULL if called on an unitialized hShape which is presumably what the code that uses it intends.
There probably should be some consistency between the naming conventions in tsShapeConstruct and tsShapeInstance since they each have hShape and mShape members, but mShape has a completly different type (StringTableEntry vs tsShape*).
Stephen
#3
09/04/2004 (2:10 pm)
Hmm. I see what's going on. Excellent research job, Stephen. I'll add that to my todo list for 1.5. I checked in the immediate fix, so we ought to have a working max2dts exporter now. 
Associate Kyle Carter