Crash when running as a managed user on Mac OS

[cygnl7]

I'm guessing running as a managed user (i.e., a non-admin account) on Mac OS isn't necessarily supported, but I post this hoping that someone has figured out how to make BZFlag work in such an account.

I'm getting a crash when I try to run BZFlag (2.0.16) from a managed account on Mac OS.
The screen goes black, the message tabs bar shows up, and then it crashes. Here's the thread that crashed:

Code: Select all

Process:         BZFlag [75844]
Path:            /Applications/BZFlag-2.0.14.app/Contents/MacOS/BZFlag
Identifier:      org.BZFlag
Version:         2.0 (2.0.14)
Code Type:       X86 (Native)
Parent Process:  launchd [890]

Date/Time:       2011-04-16 08:46:32.476 -0600
OS Version:      Mac OS X 10.6.7 (10J869)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib                   0x93b0e156 __kill + 10
1   libSystem.B.dylib                   0x93b0e148 kill$UNIX2003 + 32
2   libSystem.B.dylib                   0x93ba0899 raise + 26
3   org.BZFlag                          0x000f64ea dying(int) + 52 (playing.cxx:504)
4   ???                                 0xffffffff 0 + 4294967295
5   GLEngine                            0x18d38a69 glVertex3f_Comp + 42
6   libGL.dylib                         0x9327d746 glVertex3f + 45
7   org.BZFlag                          0x0001e81f BackgroundRenderer::makeCelestialLists(SceneRenderer const&) + 1915 (BackgroundRenderer.cxx:506)
8   ???                                 0xa0546dbc std::string::_Rep::_S_empty_rep_storage + 12

Any ideas?

[joevano]

Well you THINK you are running 2.0.16, but you are actually running 2.0.14 according to the crash report. Try 2.0.16...

[macsforme]

This was probably a safe assumption, but it does work under an admin account, presumably?

[cygnl7]

Heh, you're right. That crash report is for 2.0.14. However, the same exact stack trace happens with 2.0.16:

Code: Select all

Process:         BZFlag [76966]
Path:            /Applications/BZFlag-2.0.16.app/Contents/MacOS/BZFlag
Identifier:      org.BZFlag
Version:         2.0 (2.0.16)
Code Type:       X86 (Native)
Parent Process:  launchd [890]

Date/Time:       2011-04-16 09:20:04.553 -0600
OS Version:      Mac OS X 10.6.7 (10J869)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib                   0x93b0e156 __kill + 10
1   libSystem.B.dylib                   0x93b0e148 kill$UNIX2003 + 32
2   libSystem.B.dylib                   0x93ba0899 raise + 26
3   org.BZFlag                          0x000f672e dying(int) + 52 (playing.cxx:509)
4   ???                                 0xffffffff 0 + 4294967295
5   GLEngine                            0x198b8a69 glVertex3f_Comp + 42
6   libGL.dylib                         0x9327d746 glVertex3f + 45
7   org.BZFlag                          0x0001df33 BackgroundRenderer::makeCelestialLists(SceneRenderer const&) + 1915 (BackgroundRenderer.cxx:506)
8   ???                                 0xa0546dbc std::string::_Rep::_S_empty_rep_storage + 12

/me checks quickly to make sure it's the same... Yes; whew.

And yes, it does work under an admin account. It's my son's account that's the managed account, and I always have to let him play using my account, which is an admin account. But at least that's a workaround.

[FiringSquad]

Well, the code being run at the time of the crash is:

Code: Select all

//
// handle signals that should kill me quickly
//

static void        dying(int sig)
{
  bzSignal(sig, SIG_DFL);
  display->setDefaultResolution();
  raise(sig);
}

Of course, you can't guarantee that this is where the problem lies, but it might give a hint to somebody as to what the problem is or what to do about it.

It seems from the location though, that you get to play for a little before the crash occurs. Is that the case? Will the crash always occur on death?

My recommendation would be to do what you can to make the setup the same for both the Admin area and your son's area.
Try copying your "~/Library/Application Support/BZFlag" folder to your son's area and make sure he has full access to it.
Also check that he has full access to the Application and its package contents.

If that doesn't solve the problem then post some more details and I'll see if I can suggest something else.

[Cobra_Fast]

Will the crash always occur on death?

This is the false interpretation of the code. The code excerpt is ran when BZFlag thinks its being quit, closed or killed.
So either OSX thinks that app needs to be closed right away, the user closes it or its closing by foreign signal/failure.

As the very command that is failing is the 'raise(int)' which is supposed to send a terminal signal to the parent process, if I'm interpreting the reference documentation correctly, this issue could very likely be user-permission related.

Edit: After further research I'd bet on a permission related issue as the exception type line says that sending a SIGBUS signal is a bad call.
Looks like BZFlag needs to be ran as an administrator to fail correctly

[cygnl7]

I'm pretty sure I did already, but I'll double-check the permissions on the app support directory and files. Maybe something changed there.

Non-admin accounts always seem to have strange problems for me with mac os, especially with parental controls enabled. (And yes, his account has permissions to run BZFlag.)

I am quite familiar with Xcode and debugging, not as much with c++, and certainly not with the gl stuff, but maybe I'll see if I can hit this in the debugger and see if anything jumps out at me.

Thanks for the replies!