Jump to content
  • Advertisement
Sign in to follow this  
gjl

Crash instead of null pointer exception on opIndex

This topic is 1012 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,

 

I am migrating to AS 2.31 (more precisely revision 2301), and I am seeing a change in behavior regarding null pointer exceptions.

 

I have a class that implements an array-style opIndex. The C++ implementation is the following:

void * CollectionClass::opIndex(asUINT index)
{
    if(index<size)
        return items[index];
    else
        return NULL;
}

When accessing a collection of collection out of bounds in a script:

// out of bound: myCollection contains only 1 item
myCollection[2][2];

This used to raise a null pointer exception in the script engine (AS 2.29.2), whereas now it crashes: after checking the code in Angelscript, the null pointer check has indeed been removed, and the returned pointer is dereferenced directly to call the opIndex operator on it (as_scriptengine.cpp, line 4286):

		obj = (void*)(asPWORD(obj) + i->baseOffset);
		return (((asCSimpleDummy*)obj)->*f)(param1); 

Is this expected? Should I raise an out of bounds exception manually instead to stop execution before, like it is done in the array class?

 

I am thinking that there are probably many cases where you'd like the engine to check for null pointers for you instead, like it used to do if I remember well, but I might be wrong!

Share this post


Link to post
Share on other sites
Advertisement

How is the opIndex method registered with the engine? Is it registered to return a reference, or a handle?

 

A method that is registered to return a reference really shouldn't be allowed to return a null pointer as the reference is expected to be to a valid object. Only return a null pointer if you're also raising an exception to tell the engine that the returned reference shouldn't be accessed.

 

 

Still, I'll see what to do about this. I have a feeling that this problem was introduced in version 2.30.1 (released last year) when I added the bytecode instruction asBC_Thiscall1 to optimize access to array elements (and any other method that takes a single 32bit integer argument).

Share this post


Link to post
Share on other sites

You are right, it was indeed registered with a reference as return type - my bad! Raising an exception fixes the crash in a clean way, thanks! 

 

I guess the change in behavior indeed happened with the asBC_Thiscall1 call modification. It used to work by accident, and this is now "fixed" :-).

Share this post


Link to post
Share on other sites

There was indeed a bug in asBC_Thiscall1. Even if your first opIndex had returned a null handle (instead of a reference) it would still crash since asBC_Thiscall1 didn't verify the object pointer.

 

I've fixed this now in revision 2303.

 

Regards,

Andreas

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!