Hello, Andreas!

Something wrong with bytecode restoring compiled in x64 environment and restored in x32 environment.

LoadByteCode calls without error, but in script I've got strange 'Null pointer access'.

Please look what can be wrong, if you will not find problem then I try research this problem more.

Also I try combination of x64->x64, x32->x32, x32->x64 and it works fine.

AngelScript revision 2334, Windows, VS2015.

I'll need more information. Does it happen with all scripts? Or just some? Can you narrow it down to a specific function in the script that fails?

The byte code when saved from x64 or from x32 should be identical. Can you do a diff on the saved bytecode to find the first byte that is different, and then debug the code while saving to let me know what is being saved at that specific byte?

I have only one big module.

Here is binary code, their have same size and almost all content is identical, but with some different bytes.

Files:

http://speedy.sh/A7pMf/binary-x32.bin

http://speedy.sh/KhZH7/binary-x64.bin

This helps?

If you can also send me the engine configuration by calling WriteConfigToFile just after configuring the engine I may be able to figure out what the problem is.

http://speedy.sh/vQCEu/Config.txt

Difference only in one line:

// Lib options AS_64BIT_PTR AS_NO_EXCEPTIONS AS_WIN AS_X64_MSVC

// Lib options AS_NO_EXCEPTIONS AS_WIN AS_X86

Thanks.

I've identified that the problem is with the byte code instruction asBC_ChkNullS. This instruction is used to check if a pointer pushed on the stack is null. The offset that the instruction takes as argument must be adjusted when saving and loading the byte code according to the size of pointers.

I'll provide a solution for this as soon as possible.

I've fixed this in revision 2345.

Let me know if you find any other problems like this.

Regards,

Andreas

Works good. Thanks!