Great!
I'll give this a try, and provide a fix as soon as possible.
Linux x86-64 not loading or saving bytecode correctly.
I've reproduced the problem on the latest WIP and will be working on the fix. However, the same scenario is working OK in version 2.22.1, so it doesn't seem to be the cause of the problem that urkle reported.
The fix in 2.24 is easy.
The function AdjustGetOffset() doesn't exist in version 2.22.1. It was introduced in version 2.23.0 so the problem in 2.22.1 is definitely a different one.
Regards,
Andreas
for( asUINT p = 0; p < calledFunc->parameterTypes.GetLength(); p++ )
{
if( offset <= currOffset ) break;
// if( calledFunc->parameterTypes.GetObjectType() || <-- exchange this line for the following
if( !calledFunc->parameterTypes
.IsPrimitive() ||
calledFunc->parameterTypes
.IsReference() )
{
numPtrs++;
currOffset += AS_PTR_SIZE;
}
else
{
asASSERT( calledFunc->parameterTypes
.IsPrimitive() );
currOffset += calledFunc->parameterTypes
.GetSizeOnStackDWords();
}
}
The function AdjustGetOffset() doesn't exist in version 2.22.1. It was introduced in version 2.23.0 so the problem in 2.22.1 is definitely a different one.
Regards,
Andreas
Thanks for the prompt fix Andreas!
The bytecode saves out ok from 64 bit now.
Unfortunately I'm still having issues with loading bytecode on 64 bit.
The bytecode seems to load ok and it runs, but when it executes a function with an enum parameter, the other parameters get mangled.
For example, I have a script function:
When the scripts are compiled on x64 it works fine, but when the bytecode is loaded again, the second parameter becomes the same value as the enum.
Replacing state_types with int then casting it back to an enum to assign it fixes the problem.
There was another case with a few enums and a string that caused a crash in the string assignment operator when the function was called. This was also fixed by replacing the enums with ints.
The function I was originally having problems with also causes problems, so I'm assuming this is the same problem but manifesting itself in a different way.
I'll see if I can isolate the problem again, I suspect it will just be a matter of reloading the bytecode in the test I posted earlier.
Edit: Yep, using the same script as before but saving then loading the bytecode before executing it causes a crash, but it works if the enum is swapped for an int.
Thanks for your help!
The bytecode saves out ok from 64 bit now.
Unfortunately I'm still having issues with loading bytecode on 64 bit.
The bytecode seems to load ok and it runs, but when it executes a function with an enum parameter, the other parameters get mangled.
For example, I have a script function:
void change_state(state_types new_state, int new_face)When the scripts are compiled on x64 it works fine, but when the bytecode is loaded again, the second parameter becomes the same value as the enum.
Replacing state_types with int then casting it back to an enum to assign it fixes the problem.
There was another case with a few enums and a string that caused a crash in the string assignment operator when the function was called. This was also fixed by replacing the enums with ints.
The function I was originally having problems with also causes problems, so I'm assuming this is the same problem but manifesting itself in a different way.
I'll see if I can isolate the problem again, I suspect it will just be a matter of reloading the bytecode in the test I posted earlier.
Edit: Yep, using the same script as before but saving then loading the bytecode before executing it causes a crash, but it works if the enum is swapped for an int.
Thanks for your help!
The same fix needed to be applied in the asCReader::AdjustGetOffset() method too. I checked in that fix in revision 1373 now.
Regards,
Andreas
Regards,
Andreas
Thanks Andreas,
I was having the same issue with revision 1373, but I made the same changes in asCWriter::CalculateAdjustmentByPos() and asCReader::CalculateAdjustmentByPos()
And everything seems to be working now!
Does that sound right?
Thanks!
I was having the same issue with revision 1373, but I made the same changes in asCWriter::CalculateAdjustmentByPos() and asCReader::CalculateAdjustmentByPos()
And everything seems to be working now!
Does that sound right?
Thanks!
Yes, it sounds correct. Hopefully that was the last of them.
I'll add some further test cases to try to catch these problems and avoid that they re-occur with future changes.
I'll add some further test cases to try to catch these problems and avoid that they re-occur with future changes.
I checked in these last changes in revision 1374. Let me know if you find any further problems with the latest release.
Author
Andreas you are AWESOME! Thanks so much for turning around this bug fix (and every other bug fix you've ever turned around for me in the past ! )
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
