Sandboxed app won't run

We have an issue we haven't been able to figure out. The app launches but then doesn't completely load. If we turn off sandboxing while code-signing, it runs fine. But if we turn on sandboxing, the app just freezes during load. The console doesn't reveal much expect the following. Would any of the errors below prevent the app from running? We didn't see any gatekeeper messages.


7/19/15 3:26:12.445 AM OurApp[4635]: WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.0 instead of 10.11.0. This is not a bug in Gestalt -- it is a documented limitation. Use NSProcessInfo's operatingSystemVersion property to get correct system version number.

Call location:

7/19/15 3:26:12.448 AM OurApp[4635]: 0 CarbonCore 0x00007fff84c18ccb ___Gestalt_SystemVersion_block_invoke + 113

7/19/15 3:26:12.448 AM OurApp[4635]: 1 libdispatch.dylib 0x00007fff85cc5c11 _dispatch_client_callout + 8

7/19/15 3:26:12.448 AM OurApp[4635]: 2 libdispatch.dylib 0x00007fff85cc5b09 dispatch_once_f + 67

7/19/15 3:26:12.448 AM OurApp[4635]: 3 CarbonCore 0x00007fff84ba4b97 _Gestalt_SystemVersion + 987

7/19/15 3:26:12.448 AM OurApp[4635]: 4 CarbonCore 0x00007fff84ba3e2b Gestalt + 139

7/19/15 3:26:12.448 AM OurApp[4635]: 5 OurApp 0x0000000100eeb665 _ZN12GraphicsCaps18DetectDriverBugsGLEi + 341

7/19/15 3:26:12.448 AM OurApp[4635]: 6 OurApp 0x0000000100eeb1bd _ZN12GraphicsCaps6InitGLEv + 5197

7/19/15 3:26:16.183 AM WindowServer[194]: CGXGetConnectionProperty: Invalid connection 179275

7/19/15 3:26:16.183 AM WindowServer[194]: CGXGetConnectionProperty: Invalid connection 179275

7/19/15 3:26:16.183 AM WindowServer[194]: CGXGetConnectionProperty: Invalid connection 179275

7/19/15 3:26:16.183 AM WindowServer[194]: CGXGetConnectionProperty: Invalid connection 179275

7/19/15 3:26:16.183 AM WindowServer[194]: CGXGetConnectionProperty: Invalid connection 179275

You should force quit the app. That will generate a crash log, which will show you where the main thread is stuck.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hi Quinn


Unfortunately Force Quittig the app doesn't produce a crash log.

Indeed. Sorry about the bum steer. Try sending it a

SIGABRT
from Terminal.
$ killall -ABRT TextEdit

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

tuncer had problems posting the crash log so they sent it to me. Here's the relevant snippet:

0   libsystem_kernel.dylib      __pthread_kill + 10 
1   libsystem_pthread.dylib     pthread_kill + 90
2   libsystem_c.dylib           abort + 129
3   libmono.0.dylib             mono_handle_native_sigsegv + 732
4   libmono.0.dylib             sigabrt_signal_handler + 100
5   libsystem_platform.dylib    _sigtramp + 26
6   libsystem_kernel.dylib      mach_msg_trap + 10
7   libsystem_kernel.dylib      mach_msg + 55
8   com.apple.CoreFoundation    __CFRunLoopServiceMachPort + 212
9   com.apple.CoreFoundation    __CFRunLoopRun + 1293
10  com.apple.CoreFoundation    CFRunLoopRunSpecific + 296
11  com.apple.HIToolbox         RunCurrentEventLoopInMode + 235
12  com.apple.HIToolbox         ReceiveNextEventCommon + 432
13  com.apple.HIToolbox         _BlockUntilNextEventMatchingListInModeWith…
14  com.apple.AppKit            _DPSNextEvent + 945
15  com.apple.AppKit            -[NSApplication _nextEventMatchingEventMas…
16  com.apple.AppKit            -[NSApplication run] + 682
17  com.apple.AppKit            NSApplicationMain + 1176
18  com.mpdigital.Infinifactory PlayerMain(int, char const**) + 738
19  com.mpdigital.Infinifactory start + 52

Alas, the results are inconclusive. The app seems to be written in Mono, something I'm not particularly familiar with. Frames 0 through 4 may well be an artefact of the way that the Mono handled the incoming

SIGABRT
, in which case they're a complete red herring. Below frame 4 everything looks like a standard run loop that's processing events.

tuncer, if you run the app from Finder and then, once it's hang, attach with the debugger, what sort of background do you see?

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I noticed something that might provide some answers. Not sure if I'm on the righ ttrack here...


The game has 4 Plugins in the Plugins folder:


fmod.bundle

fmodL.bundle

fmodstudio.bundle

fmodstudioL.bundle


While each of these are code-signed (there's a _CodeSignature) in each of these bundles, each plugin is missing an info.plist file and a Resources folder inside. There's only an executable in the MacOS folders. Could that make Gatekeeper block them from running, even though they are code-signed?

Possibly, but if Gatekeeper was unhappy with your app it should say so, not just cause the app to hang at launch.

You can check what code signing and Gatekeeper think of your app with the following commands.

$ codesign -vvv --deep /Applications/iTunes.app
$ spctl --assess --raw /Applications/iTunes.app

Note On 10.11 and later, also pass

--strict
to
codesign
.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"
Sandboxed app won't run
 
 
Q