I'm using 2.28.1 WIP on debug, 32-bit windows 7.
I have a wrapper function around engine->GetTypeIdByDecl() along these lines:
i32 GetEngineTypeIdFromDecl(string s)
{
if ( s is in container )
// return cached int from container
else
{
// call engine->GetTypeIdByDecl(s)
// add int to container
// return int
}
}
I've run into a crash in engine->GetObjectTypeById():
asIObjectType *asCScriptEngine::GetObjectTypeById(int typeId) const
{
asCDataType dt = GetDataTypeFromTypeId(typeId);
// Is the type id valid?
if( !dt.IsValid() ) return 0;
// Enum types are not objects, so we shouldn't return an object type for them
if( dt.GetObjectType() && dt.GetObjectType()->GetFlags() & asOBJ_ENUM )
return 0;
return dt.GetObjectType();
}
dt, as it comes back from GetDataTypeFromTypeId(typeId) is a garbage instance.. it passes the valid check but crashes in the dt.GetObjectType()-> call.. I noticed in the debugger that many of dt's variables are 0xfeeefeee which VS's debug allocator uses to indicate that you're pointing to deleted heap memory.
Here is what I'm doing:
void MyExecuteScriptFunction(functionName, paramsForFunction)
{
// this potentially returns a cached typeid
i32 myArrayTypeId = GetEngineTypeIdFromDecl("array<MyType@>@");
// the second time I run through this code, the below call crashes:
asIObjectType* type engine->GetObjectTypeById(myArrayTypeId);
CScriptArray* arr = new CScriptArray(0, type);
// fill array with some stuff, pass it to a script function, execute function
arr->Release();
}
I can get around the crash either by leaking the CScriptArray, which means its dtor doesn't run and it doesn't call Release() on the object type, or I can avoid caching the results of engine->GetTypeIdByDecl() and call it every time.
CScriptArray::~CScriptArray()
{
...
if( objType ) objType->Release();
}
Since the AngelScript documentation suggests caching the results of engine->GetTypeIdByDecl(), am I doing anything wrong above? Is there any way for me to know that my cached type id has been invalidated?
Thank you very much.