Jump to content

OS X bus error


Recommended Posts

Hello,

I have finally managed to compile on OS X, but when I try to run pyrogenesis_dbg I get this error:

TIMER| InitVfs: 2.943 ms
Bus error

I tried to run it trough gdb and it gave this output:

TIMER| InitVfs: 3.18 ms

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000001
0x00c5d7e3 in JS_DefineFunction ()

I have compiled on two OS X computers now, and both get exactly the same error.

The first time I built I accidentally misread the build instructions and compiled without a proper installation of libdevil(without ILU and ILUT). The compilation quitted, but the game was compiled, and I managed to launch it without a bus error and get to the Main Menu. It crashed when I tried to play a game(probably because everything was not compiled).

It might be something after the build errors caused by a corrupt libdevil installation, that causes my bus error.

Link to comment
Share on other sites

hm, that's a strange one. We don't actually call JS_DefineFunction, it's probably being invoked from one of several JS_DefineFunctions. Could you please add printfs to those four spots to try and determine which of its parameters is equal to 1?

BTW, I hope "bus error" isn't due to the address being unaligned. Are you running OS X on an x86 processor? I doubt we'll currently run on PPC due to possible endianess and alignment bugs.

Link to comment
Share on other sites

I added lots of printfs and it seems like the error is caused by a call to JS_DefineFunctions in ScriptingHost::ScriptingHost() in source/scripting/ScriptingHost.cpp.

I tried to comment the lines, but then another call to JS_DefineFunction in JS_InitClass in ScriptingHost::DefineCustomObjectType made it crash. Maybe there are more than one call to JS_DefineFunction that causes the error?

I am on a x86 processor, so everything should hopefully work.

Link to comment
Share on other sites

It's good that you're running x86, that at least gives us hope ;)

We might be running into trouble with the SpiderMonkey library itself - their versions and capabilities (most importantly: thread-safety) differ. I would have thought the recent step of adding our own SM branch to SVN solves this problem, but maybe it isn't actually being used/compiled. Would you like to try adding an #error to some files in libraries/spidermonkey/src and /include and recompiling?

If indeed your locally installed SpiderMonkey was being used, we'll need to change that, but unfortunately I have no idea how (Windows user :P ).

Link to comment
Share on other sites

It works!

You were right, it compiled with my local installation of Spidermonkey. I "fixed" it by simply uninstalling Spidermonkey. I still got some errors while running, but it was possible to skip them(I can post the errors if you need them). I will try to see if I can figure out a way to compile without uninstalling Spidermonkey, but that will be later. Now I am going to play the game ;):P.

Link to comment
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
 Share

×
×
  • Create New...