You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I found that for pos == OP_Last, pos == OP_First and pos == OP_This the return value was not being placed into the correct VM stack location and was infact clobbering an argument instead of using the reserved return space.
This works fine with the following AngelScript function (presumably) because the arguments are local copies, releasing the return value string generally has no ill effect:
string foo( string, string )
however if the function is changed to:
string foo( const string& in, const string& in )
then the return value is released and this corrupts the overwritten string reference and causes a crash.
I have modified our version of call_64conv to the following:
Just another note on this one as I realised it is not very clear
The issue is with OP_This, where the return value space is in the first stack position stack[0] and objPointer is NULL so therefore the original code falls through and generates the code for the second stack poition.
Hi,
I found an issue when using AngelScript 2.35.1 (note that this is probably not version specific) and MSVC
In the function
SystemCall::call_64conv
inas_jit.cpp
there is this code:I found that for
pos == OP_Last
,pos == OP_First
andpos == OP_This
the return value was not being placed into the correct VM stack location and was infact clobbering an argument instead of using the reserved return space.This works fine with the following AngelScript function (presumably) because the arguments are local copies, releasing the return value string generally has no ill effect:
string foo( string, string )
however if the function is changed to:
string foo( const string& in, const string& in )
then the return value is released and this corrupts the overwritten string reference and causes a crash.
I have modified our version of
call_64conv
to the following:This is now working for me and the arguments are written into the correct VM stack location. Maybe you can come up with a better fix for this?
Thanks,
Tom
The text was updated successfully, but these errors were encountered: