• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Vasil Boshnyakov

Mac OS X 32-bits crash

28 posts in this topic

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
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
Running tutorial:

[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left]as_callfunc_x86.cpp: [/left][/size][/font][/color][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left]CallSystemFunctionNative()[/left][/size][/font][/color]


[b]Executing the script.[/b]
[b]---[/b]
[b]name: _string_factory_[/b]
[b]objectType: NULL[/b]
[b]parameterTypes.length: 2[/b]

About the next idea:
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left]... change the value of the CLEAR_FPU_STACK define on line 68 in as_callfunc_x86.cpp to emms.[/left][/size][/font][/color]
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left]no difference. [/left][/size][/font][/color]
The application always crashes on row (around) 317 - the first asm __volatile__(
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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
[url="http://pastebin.com/UZagTvCa"]http://pastebin.com/UZagTvCa[/url]

Let me know if there's anything else I can do.
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
The disassembly of the StringFactory doesn't show any difference in the calling convention. It is taking the function arguments on the stack, returning the value in eax, and makes sure not to modify the registers ebp, ebx, esi, and edi.
0

Share this post


Link to post
Share on other sites
It might be a difference in one of the other calling conventions. The fact that it fails when calling the StringFactory may not mean the problem is with the StringFactory itself, it could be a previous call that is causing the problem.

Can you run the test_features project (from the svn)? I need to see which of the following tests pass:

[code]

// The following tests are designed specifically to test the native calling conventions.
// These are grouped by calling convention and ordered in increasing complexity.
{
// cdecl
if( TestExecute() ) goto failed; else printf("-- TestExecute passed\n");
if( TestCDeclReturn::Test() ) goto failed; else printf("-- TestCDeclReturn passed\n");
if( TestExecute1Arg() ) goto failed; else printf("-- TestExecute1Arg passed\n");
if( TestExecute2Args() ) goto failed; else printf("-- TestExecute2Args passed\n");
if( TestExecute4Args() ) goto failed; else printf("-- TestExecute4Args passed\n");
if( TestExecute4Argsf() ) goto failed; else printf("-- TestExecute4Argsf passed\n");
if( TestExecuteMixedArgs() ) goto failed; else printf("-- TestExecuteMixedArgs passed\n");
if( TestExecute32Args() ) goto failed; else printf("-- TestExecute32Args passed\n");
if( TestExecute32MixedArgs() ) goto failed; else printf("-- TestExecute32MixedArgs passed\n");
if( TestCDecl_Class() ) goto failed; else printf("-- TestCDecl_Class passed\n");
if( TestCDecl_ClassA() ) goto failed; else printf("-- TestCDecl_ClassA passed\n");
if( TestCDecl_ClassC() ) goto failed; else printf("-- TestCDecl_ClassC passed\n");
if( TestCDecl_ClassD() ) goto failed; else printf("-- TestCDecl_ClassD passed\n");
if( TestCDecl_ClassK() ) goto failed; else printf("-- TestCDecl_ClassK passed\n");

// cdecl_objlast and cdecl_objfirst
if( TestReturnString::Test() ) goto failed; else printf("-- TestReturnString passed\n");
if( TestNegateOperator() ) goto failed; else printf("-- TestNegateOperator passed\n");
if( TestReturnWithCDeclObjFirst() ) goto failed; else printf("-- TestReturnWithCDeclObjFirst passed\n");

// thiscall
if( TestExecuteThis32MixedArgs() ) goto failed; else printf("-- TestExecuteThis32MixedArgs passed\n");
if( TestNotComplexThisCall() ) goto failed; else printf("-- TestNotComplexThisCall passed\n");
if( TestVirtualMethod() ) goto failed; else printf("-- TestVirtualMethod passed\n");
if( TestMultipleInheritance() ) goto failed; else printf("-- TestMultipleInheritance passed\n");
if( TestVirtualInheritance() ) goto failed; else printf("-- TestVirtualInheritance passed\n");

// stdcall
if( TestStdcall4Args() ) goto failed; else printf("-- TestStdcall4Args passed\n");
if( TestNotComplexStdcall() ) goto failed; else printf("-- TestNotComplexStdcall passed\n");
}
[/code]

Comment out all the other tests above these in the main() function (in main.cpp), as they test features, etc. But before those will work the native calling conventions must work.

Based on which of the tests for the calling conventions that work or not it should be easier to narrow in on where the problem really lies.
0

Share this post


Link to post
Share on other sites
Every one of the tests crashes inside [font=courier new,courier,monospace]CallSystemFunctionNative[/font] when it gets to "[font=courier new,courier,monospace]asm __volatile__[/font]"

[font=courier new,courier,monospace]TestExecute [/font]crashes calling "[font=courier new,courier,monospace]cfunction[/font]" from "[font=courier new,courier,monospace]ExecuteString[/font]"
[font=courier new,courier,monospace]TestCDeclReturn::Test[/font] crashes calling "[font=courier new,courier,monospace]reti64[/font]" from "[font=courier new,courier,monospace]ExecuteString[/font]"
[font=courier new,courier,monospace]TestExecute1Arg [/font]crashes calling "[font=courier new,courier,monospace]cfunction[/font]"
...etc

Only one that didn't crash was [font=courier new,courier,monospace]TestVirtualInheritance[/font], but I think it got skipped because virtual inheritance wasn't detected.

Let me know if there's anything more I can do.

Edit: I'm on
[left]OS 10.7.3 and Xcode 4.3.2[/left]

[left]Edit 2: If I compile for 64 bit, all tests pass (Except TextVirtualInheritance which is skipped).[/left]
0

Share this post


Link to post
Share on other sites
If all of them crashes, then I can only think that the inline assembly in as_callfunc_x86.cpp is causing this.

Something is going wrong when the code is being compiled.

I'll need the assembler code produced for the CallCDeclFunction(). The same way you sent it for the StringFactory.

Hopefully I'll spot what is wrong. It might be a register that is getting incorrectly mangled (though the inline assembler is using the clobber lists).




[edit]

Matt, in [url="http://www.gamedev.net/topic/621357-porting-dustforce-to-os-x/"]your previous post[/url] you were using XCode 4.2.1. Was that with Mac OS 10.7.3? or a previous version of Mac OS too? At that time we got it to work. I'm wondering if this might not be a bug in XCode itself (or rather the compiler it is using).
0

Share this post


Link to post
Share on other sites
I think I was on 10.7.2 and I updated to 10.7.3 when I updated Xcode.
Can't remember if I tried 2.23.0 before updating or not, sorry.

Here's the assembly for CallCDeclFunction, I think
[url="http://pastebin.com/VpMwk3HF"]http://pastebin.com/VpMwk3HF[/url]

Thanks

Edit: Btw, it's crashing on line 47 of that paste, 2 lines after "[font=courier new,courier,monospace]copyloop:"[/font] at "[font=courier new,courier,monospace][color=#000000]pushl [/color][color=#009900][b]([/b][/color][color=#339933]%[/color][color=#00007F]eax[/color][color=#009900][b])[/b][/color][color=#000000]"[/color][/font]
0

Share this post


Link to post
Share on other sites
In which test does it crash on this line? The TextExecute() test? It shouldn't even be hitting that instruction in that test.

I'm not seeing anything wrong with the assembly that was produced.

I can only imagine that LLVM that XCode is using is not recognizing some instructions, possibly "pushl (%eax)". It's a longshot, but perhaps changing the inline assembly a bit might work. Can you try changing the inline assembly in CallCDeclFunction to the following:

[code]

asm __volatile__(
_S(CLEAR_FPU_STACK) "\n"
"pushl %%ebx \n"
"movl %%edx, %%ebx \n"

// Need to align the stack pointer so that it is aligned to 16 bytes when making the function call.
// It is assumed that when entering this function, the stack pointer is already aligned, so we need
// to calculate how much we will put on the stack during this call.
"movl 4(%%ebx), %%eax \n" // paramSize
"addl $4, %%eax \n" // counting esp that we will push on the stack
"movl %%esp, %%ecx \n"
"subl %%eax, %%ecx \n"
"andl $15, %%ecx \n"
"movl %%esp, %%eax \n"
"subl %%ecx, %%esp \n"
"pushl %%eax \n" // Store the original stack pointer

"movl 4(%%ebx), %%ecx \n" // paramSize
"movl 0(%%ebx), %%eax \n" // args
"addl %%ecx, %%eax \n" // push arguments on the stack
"cmp $0, %%ecx \n"
"je endcopy \n"
"copyloop: \n"
"subl $4, %%eax \n"
// "pushl (%%eax) \n" <----- comment out
"movl (%%eax), %%edx \n" <----- add
"pushl %%edx \n" <----- add
"subl $4, %%ecx \n"
"cmp $0, %%ecx \n" <------ add
"jne copyloop \n"
"endcopy: \n"
"call *8(%%ebx) \n"
"addl 4(%%ebx), %%esp \n" // pop arguments

// Pop the alignment bytes
"popl %%esp \n"
"popl %%ebx \n"
: // output
: "d"(&args) // input - pass pointer of args in edx
: "%eax", "%ecx", "%esp" // clobber
);
[/code]

I replaced the 'pushl (%%eax)' with 'movl (%%eax), %%edx' and 'pushl %%edx'. Then I also added an explicit 'cmp $0, %%ecx' before the jne instruction.

Neither of these changes should be necessary, but who knows what LLVM does.
0

Share this post


Link to post
Share on other sites
Yep, this is in [font=courier new,courier,monospace]TestExecute()[/font]
I tried that code, it still crashes. This is what it looks like when it crashes with call stack and disassembly:
[url="http://snag.gy/jDB74.jpg"]http://snag.gy/jDB74.jpg[/url]
0

Share this post


Link to post
Share on other sites
OK. So the code changes didn't make a difference. The problem is happening when attempting to access the memory pointed to by the address in eax.

TestExecute() is calling a global function without any arguments, so it shouldn't even try to push any arguments on the stack.

Do you think you can single step through the CallCDeclFunction() at assembler level and check what the values are on the registers? The code really should be jumping to endcopy at the first 'je endcopy'. For some reason it isn't doing that, and instead tries to read from 'eax' that is seemingly pointing to some invalid memory position.
0

Share this post


Link to post
Share on other sites
Nevermind. I figured it out.

In the inline assembly I'm asking the compiler to pass the address of the parameter 'args' in the edx register. I'm then using this address to determine the location of the other two parameters so I do not have to rely on ebp or esp to get to them. Relying on ebp or esp is not possible because they are used differently in different optimization levels.

The problem here is that for some reason the compiler is not passing the address of the parameter, but instead the address of a local temporary variable with the same value. Because of this my code fails to retrieve the correct values for 'paramSize' and 'func'.

I'll have to rewrite the inline assembly to pass each of the values in explicit registers to avoid this unexpected behaviour.

Thanks for all the help in figuring this out.

Unfortunately I'll be traveling today, and will only be back in a week. I will only be able to work on this fix when I get back.
1

Share this post


Link to post
Share on other sites
One thing that might resolve the problem until I get to reimplement the inline assembler code is to remove the macros "UNUSED_VAR()" in the CallCDeclFunction, etc. It might be because of these macros that the compiler decides to copy the parameters to local variables.
0

Share this post


Link to post
Share on other sites
Unfortunately removing the UNUSED_VAR macros doesn't help.

Are you sure it's not passing the address of the parameter?
It looks correct here:
http://snag.gy/q98dS.jpg

Down the bottom of the image you can see that
[font=courier new,courier,monospace]&args[/font] is [font=courier new,courier,monospace]0xbffff294[/font]
[font=courier new,courier,monospace]&paramSize[/font] is [font=courier new,courier,monospace]0xbffff290 (-4)[/font]
and [font=courier new,courier,monospace]&func[/font] is [font=courier new,courier,monospace]0xbffff28c (-8)[/font]
And [font=courier new,courier,monospace]edx[/font] seems to be set to [font=courier new,courier,monospace]0xbffff294[/font].

Thanks for your help, and no rush, 1.22.1 is still working.
And the mac build of Dustforce isn't out for another 3 weeks :P
0

Share this post


Link to post
Share on other sites
Yes, I'm sure. The paramSize should be at an address 4 bytes higher than args not lower.

You're seeing the addresses of the local variables, and not the arguments. If the local variables had been layed out in the same order as the arguments then it would still have worked, but unfortunately the order was inverted inverted.


0

Share this post


Link to post
Share on other sites
Ah, you're right. If I put the function parameters in an array on the stack in the correct order, and pass that array in to the assembly code it works, in debug at least.
0

Share this post


Link to post
Share on other sites
I've fixed this problem now in revision 1269. At least the changes I did is working on Linux, but then, it was working before too.

I ended up putting the function arguments in a local array like you did in your test. That is only solution I found that worked for all of the functions. The functions that has fewer arguments could be solved by passing each argument in individual registers, but that would require more changes and would make the code less maintainable.

I'd appreciate it if both Matt and Vasil can confirm that the changes have fixed the problem.
0

Share this post


Link to post
Share on other sites
This is what I'm getting if I run just the native calling convention tests:

Same in debug/release apple/gcc compiler

[quote]
[b]AngelScript version: 2.23.1 WIP[/b]
[b]AngelScript options: AS_MAC AS_X86 [/b]
[b]-- TestExecute passed[/b]
[b]--- Assert failed ---[/b]
[b]func: void ExecuteString()[/b]
[b]mdle: ExecuteString[/b]
[b]sect: ExecuteString[/b]
[b]line: 1[/b]
[b]---------------------[/b]
[b]Failed on line 76 in /Users/Matt/Downloads/trunk 2/sdk/tests/test_feature/projects/xcode/../../source/test_cdecl_return.cpp[/b]

[b]TestReturn: cfunction didn't return properly[/b]

[b]Failed on line 84 in /Users/Matt/Downloads/trunk 2/sdk/tests/test_feature/projects/xcode/../../source/test_cdecl_return.cpp[/b]
[b]--- Assert failed ---[/b]
[b]func: void ExecuteString()[/b]
[b]mdle: ExecuteString[/b]
[b]sect: ExecuteString[/b]
[b]line: 1[/b]
[b]---------------------[/b]
[b]Failed on line 88 in /Users/Matt/Downloads/trunk 2/sdk/tests/test_feature/projects/xcode/../../source/test_cdecl_return.cpp[/b]
[b]--- Assert failed ---[/b]
[b]func: void ExecuteString()[/b]
[b]mdle: ExecuteString[/b]
[b]sect: ExecuteString[/b]
[b]line: 1[/b]
[b]---------------------[/b]
[b]Failed on line 100 in /Users/Matt/Downloads/trunk 2/sdk/tests/test_feature/projects/xcode/../../source/test_cdecl_return.cpp[/b]
[b]Failed on line 248 in /Users/Matt/Downloads/trunk 2/sdk/tests/test_feature/projects/xcode/../../source/test_cdecl_return.cpp[/b]
[b]--------------------------------------------[/b]
[b]One of the tests failed, see details above.[/b]
[/quote]

I'll see if I can get a better idea of what's going wrong, let me know if there's any other information I can give you.

I don't know if you have any interest in upgrading your mac, and please don't feel obligated to do so.
But I just made a small donation on behalf of Hitbox for your contribution to Dustforce, which might help out if you did want to upgrade.

Thanks,
Matt
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0