Hello,
when I compile "tutorial" example to MacOS X 64 bits, everything works normal. When I switch to 32 bits (Intel 32 bits) the application crashes (please check the attached file).
Any help how to get it working is greatly appreciated! Thank you!
Best regards, Vasil
Mac OS X 32-bits crash
Hi, Vasil,
which version of AngelScript are you using? Are you compiling the library with optimizations turned on or off?
I fixed a similar crash on Mac OS X 32bit in version 2.23.0 thanks to the help from Matt Bush.
Regards,
Andreas
which version of AngelScript are you using? Are you compiling the library with optimizations turned on or off?
I fixed a similar crash on Mac OS X 32bit in version 2.23.0 thanks to the help from Matt Bush.
Regards,
Andreas
Author
Hello Andreas,
thank you for your reply.
Here is more detailed information:
AngelScript library 2.23.0
The platform is Mac OS 10.7.3 (Lion)
XCode 4.3.2 (the latest)
Create new project for Mac OS X - command line tool
Select "Type: C++", No Automated Reference Counting
replace "main.cpp" the file from "tutorial".
Add to the same folder angelscript.h + all source files + scriptarray + scriptstdstring
Fix the include defines (#include <angelscript.h> -> #include "angelscript.h")
Compile and run the project in 64 bits (Debug) - works
Compile and run the project in 64 bits (Release) - works
Add 32 bits support:
Compile and run the project in 32 bits (Debug) - check attachment1.png
Compile and run the project in 32 bits (Release) - check attachment2.png
The only two files for the callfunc are:
as_callfunc_x64_gcc.cpp
as_callfunc_x86.cpp
Thank you for your help!
Best regards, Vasil
thank you for your reply.
Here is more detailed information:
AngelScript library 2.23.0
The platform is Mac OS 10.7.3 (Lion)
XCode 4.3.2 (the latest)
Create new project for Mac OS X - command line tool
Select "Type: C++", No Automated Reference Counting
replace "main.cpp" the file from "tutorial".
Add to the same folder angelscript.h + all source files + scriptarray + scriptstdstring
Fix the include defines (#include <angelscript.h> -> #include "angelscript.h")
Compile and run the project in 64 bits (Debug) - works
Compile and run the project in 64 bits (Release) - works
Add 32 bits support:
Compile and run the project in 32 bits (Debug) - check attachment1.png
Compile and run the project in 32 bits (Release) - check attachment2.png
The only two files for the callfunc are:
as_callfunc_x64_gcc.cpp
as_callfunc_x86.cpp
Thank you for your help!
Best regards, Vasil
Thanks. I'll try to reproduce the problem on my old Mac.
However, I'm pretty sure this is a problem that only happens with the new CLang compiler that Apple has adopted lately for their development tools. If this is the case, then I'll most likely need your help to debug and find the cause for the problem.
However, I'm pretty sure this is a problem that only happens with the new CLang compiler that Apple has adopted lately for their development tools. If this is the case, then I'll most likely need your help to debug and find the cause for the problem.
Author
Thank you! I will help you to fix this problem (just give me a task).
I have changed the compiler to LLVM GCC 4.2 (Instead of Apple LLVM Compiler 3.1) and the problem still exists.
I have changed the compiler to LLVM GCC 4.2 (Instead of Apple LLVM Compiler 3.1) and the problem still exists.
As I suspected; I was not able to reproduce this on my old Mac. My Mac is still running Mac OS X 10.4.11 with XCode 2.4.1, and AngelScript still runs without a problem on it. The problem you're facing really must be something triggered by this new version of the compiler that you have.
OK. I guess we'll have to do this the hard way, with me trying to guide you through the debugging process until we find the problem and I can have it fixed.
The first thing I need to know is which registered function AngelScript is trying to call when it crashes. Can you set a breakpoint in the CallSystemFunctionNative() in the as_callfunc_x86.cpp file, and there let me know the values of the following variables?
- descr->name
- descr->objectType
- descr->parameterTypes.length
This will let me know which function is being called when the crash happens, and then I can determine what to expect from the rest of the values. We will then have to debug step by step until we find out where something goes wrong.
This will unfortunately be a long process if I have to guide you through each step, so hopefully you are willing to do a little debugging on your own and try to figure out why it is not working.
One thing that you can try that might solve the problem is to change the value of the CLEAR_FPU_STACK define on line 68 in as_callfunc_x86.cpp to emms. This will change the way the FPU stack is cleared with each call. It might be this that is causing the crash, though I just making a wild guess here.
OK. I guess we'll have to do this the hard way, with me trying to guide you through the debugging process until we find the problem and I can have it fixed.
The first thing I need to know is which registered function AngelScript is trying to call when it crashes. Can you set a breakpoint in the CallSystemFunctionNative() in the as_callfunc_x86.cpp file, and there let me know the values of the following variables?
- descr->name
- descr->objectType
- descr->parameterTypes.length
This will let me know which function is being called when the crash happens, and then I can determine what to expect from the rest of the values. We will then have to debug step by step until we find out where something goes wrong.
This will unfortunately be a long process if I have to guide you through each step, so hopefully you are willing to do a little debugging on your own and try to figure out why it is not working.
One thing that you can try that might solve the problem is to change the value of the CLEAR_FPU_STACK define on line 68 in as_callfunc_x86.cpp to emms. This will change the way the FPU stack is cleared with each call. It might be this that is causing the crash, though I just making a wild guess here.
Author
Running tutorial:
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]
Executing the script.
---
name: _string_factory_
objectType: NULL
parameterTypes.length: 2
About the next idea:
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]
The application always crashes on row (around) 317 - the first asm __volatile__(
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]
as_callfunc_x86.cpp:
[/font][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]CallSystemFunctionNative()
[/font]Executing the script.
---
name: _string_factory_
objectType: NULL
parameterTypes.length: 2
About the next idea:
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]
... change the value of the CLEAR_FPU_STACK define on line 68 in as_callfunc_x86.cpp to emms.
[/font][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]
no difference.
[/font]The application always crashes on row (around) 317 - the first asm __volatile__(
Can you show me the disassembly of the StringFactory() function in the add_on/scriptstdstring/scriptstdstring.cpp file?
I suspect the inline assembler code I has is not compatible with what the new LLVM compiler generates (whether it be Clang or GCC). If I can see the disassembly I may be able to identify the difference.
I suspect the inline assembler code I has is not compatible with what the new LLVM compiler generates (whether it be Clang or GCC). If I can see the disassembly I may be able to identify the difference.
Hey Andreas,
I'm having the same issue, I couldn't get the disassembly to work, but here's the assembly from what I think is the StringFactory function
http://pastebin.com/UZagTvCa
Let me know if there's anything else I can do.
I'm having the same issue, I couldn't get the disassembly to work, but here's the assembly from what I think is the StringFactory function
http://pastebin.com/UZagTvCa
Let me know if there's anything else I can do.
Hi Matt,
are you using the same version of Mac and XCode as Vasil is? I.e. Mac OS 10.7.3 and XCode 4.3.2?
I'll check out the pastebin content when I get home to see if I can figure out what's causing the problem.
Regards,
Andreas
are you using the same version of Mac and XCode as Vasil is? I.e. Mac OS 10.7.3 and XCode 4.3.2?
I'll check out the pastebin content when I get home to see if I can figure out what's causing the problem.
Regards,
Andreas
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement