• Advertisement
Sign in to follow this  

Assert in as_compiler.cpp, temp variables

This topic is 1825 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

for some of the latest AngelScript versions I've been getting an assert in as_compiler.cpp, function CompileStatementBlock, asASSERT( tempVariables.GetLength() == 0; ) . This still persists in the latest SVN revision.

 

I seem to be able to trigger it (at least) with the following if statement, where RayQueryResult is a value type, Drawable is a reference type, and String is a value type string adapted from the AngelScript addons.

 

 

RayQueryResult res;
if (res.drawable.typename == "AnimatedModel") // compiling this triggers the assert
{
  Print("is animated");
}

 

If I split up the if statement as follows, it will not assert:

 

 

RayQueryResult res;
Drawable@ dr = res.drawable;
if (dr.typename == "AnimatedModel")
{
  Print("is animated");
}

 

 

The relevant class and function registrations should be:

 

 

engine->RegisterObjectType("String", sizeof(String), asOBJ_VALUE | asOBJ_APP_CLASS_CDAK);
engine->RegisterStringFactory("String", asFUNCTION(StringFactory), asCALL_CDECL);
engine->RegisterObjectMethod("String", "bool opEquals(const String&in) const", asMETHODPR(String, operator ==, (const String&) const, bool), asCALL_THISCALL);
 
engine->RegisterObjectType("Drawable", 0, asOBJ_REF);
engine->RegisterObjectMethod("Drawable", "const String& get_typeName() const", asMETHODPR(Drawable, GetTypeName, () const, const String&), asCALL_THISCALL);
 
engine->RegisterObjectType("RayQueryResult", sizeof(RayQueryResult), asOBJ_VALUE | asOBJ_POD | asOBJ_APP_CLASS_C);
engine->RegisterObjectBehaviour("RayQueryResult", asBEHAVE_CONSTRUCT, "void f()", asFUNCTION(ConstructRayQueryResult), asCALL_CDECL_OBJLAST);
engine->RegisterObjectMethod("RayQueryResult", "Drawable@+ get_drawable() const", asFUNCTION(RayQueryResultGetDrawable), asCALL_CDECL_OBJLAST);
Edited by AgentC

Share this post


Link to post
Share on other sites
Advertisement

The bugs weren't related after all. In fact the bug you reported isn't specific for unsafe references as it's reproduceable even without allowing unsafe references. 

 

I'm still investigating the cause but it appears to be related to the virtual property accessors, especially the nested access of a virtual property on a virtual property. 

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement