I’m using a new SDK which has a callback function. I’ve dealt with this sort of thing successfully and unsuccessfully before…
I get a crash on the callback but I’m not sure how to tell what is causing it.
I’m concerned that the callback is in a different thread (which would probably necessitate incorporating the SDK into a plug-in - hence posting in this channel) but I might be simply setting things up wrong.
FYI, I am calling back to a shared method and I’m pretty sure the shared method is set up correctly for the incoming parameters.
How to tell?
Here’s a snippet of the crash log
Time Awake Since Boot: 450000 seconds
Crashed Thread: 12
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000b07b0fec
VM Regions Near 0xb07b0fec:
Stack 00000000b06ad000-00000000b072e000 [ 516K] rw-/rwx SM=COW
--> Stack 00000000b07b0000-00000000b07b1000 [ 4K] ---/rwx SM=NUL
Stack 00000000b07b1000-00000000b0832000 [ 516K] rw-/rwx SM=COW
Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x919eb9ce mach_msg_trap + 10
1 libsystem_kernel.dylib 0x919eaa70 mach_msg + 68
2 com.apple.CoreFoundation 0x98e3cef6 __CFRunLoopServiceMachPort + 214
3 com.apple.CoreFoundation 0x98e3c309 __CFRunLoopRun + 1529
4 com.apple.CoreFoundation 0x98e3baa6 CFRunLoopRunSpecific + 390
5 com.apple.CoreFoundation 0x98e3b90b CFRunLoopRunInMode + 123
6 com.apple.HIToolbox 0x960a28f8 RunCurrentEventLoopInMode + 262
7 com.apple.HIToolbox 0x960a2631 ReceiveNextEventCommon + 494
8 com.apple.HIToolbox 0x960a242c _BlockUntilNextEventMatchingListInModeWithFilter + 99
9 com.apple.AppKit 0x90769b41 _DPSNextEvent + 742
10 com.apple.AppKit 0x907691e5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 350
11 com.xojo.XojoFramework 0x016526e0 0x161f000 + 210656
12 com.xojo.XojoFramework 0x01652746 0x161f000 + 210758any ideas?
good point, I missed that it was Thread 12. I’ve included info about it below.
I’ve just discovered that two of my background threads crashed the app. Both of them at “me.Sleep(threadSleepTimeMSec)” with stack overflow exceptions. Neither of them are involved with the SDK or callback in any way.
These are typically well-behaved threads, something in the callback is causing them to run uncontrollably?
Working on disabling them temporarily to see what happens next…
Thread 12 Crashed:
0 libsystem_malloc.dylib 0x924a73f4 szone_malloc_should_clear + 13
1 libsystem_malloc.dylib 0x924aa4a4 szone_calloc + 62
2 libsystem_malloc.dylib 0x924aa422 malloc_zone_calloc + 82
3 libsystem_malloc.dylib 0x924aacab calloc + 60
4 com.xojo.XojoFramework 0x01748af7 0x161f000 + 1219319
5 com.xojo.XojoFramework 0x0177aae1 RuntimeNewObject + 142
6 com.xojo.XojoFramework 0x0165aec9 0x161f000 + 245449
7 com.xojo.XojoFramework 0x0171dcd7 0x161f000 + 1043671
8 com.xojo.XojoFramework 0x017858bd RuntimeStackCheck + 73
9 <my app> 0x006f41a8 App.Event_UnhandledException%b%o<App>o<RuntimeException> + 179
10 com.xojo.XojoFramework 0x016c0928 TryApplicationUnhandledException + 153
11 com.xojo.XojoFramework 0x017787f7 0x161f000 + 1415159
12 <my app> 0x006f493e App.Event_UnhandledException%b%o<App>o<RuntimeException> + 2121
13 com.xojo.XojoFramework 0x016c0928 TryApplicationUnhandledException + 153
14 com.xojo.XojoFramework 0x017787f7 0x161f000 + 1415159
15 <my app> 0x006f493e App.Event_UnhandledException%b%o<App>o<RuntimeException> + 2121
16 com.xojo.XojoFramework 0x016c0928 TryApplicationUnhandledException + 153
17 com.xojo.XojoFramework 0x017787f7 0x161f000 + 1415159
18 <my app> 0x006f493e App.Event_UnhandledException%b%o<App>o<RuntimeException> + 2121
19 com.xojo.XojoFramework 0x016c0928 TryApplicationUnhandledException + 153
20 com.xojo.XojoFramework 0x017787f7 0x161f000 + 1415159
21 <my app> 0x006f493e App.Event_UnhandledException%b%o<App>o<RuntimeException> + 2121
22 com.xojo.XojoFramework 0x016c0928 TryApplicationUnhandledException + 153
23 com.xojo.XojoFramework 0x017787f7 0x161f000 + 1415159
24 <my app> 0x006f493e App.Event_UnhandledException%b%o<App>o<RuntimeException> + 2121
[quote=252236:@Steve Upton]I’ve just discovered that two of my background threads crashed the app. Both of them at “me.Sleep(threadSleepTimeMSec)” with stack overflow exceptions. Neither of them are involved with the SDK or callback in any way.
These are typically well-behaved threads, something in the callback is causing them to run uncontrollably?[/quote]
If I had to guess, I’d say these are non-Xojo threads that have been made to execute Xojo code.
well, not really.
But as I suspected, they were a red herring. After disabling the threads (not essential to the SDK function), I still get a crash.
First, it jumps back to the debugger multiple times. There’s no stop point in sight, but I have to hit “play” to get it to continue.
Finally it crashed again with:
Crashed Thread: 10
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000000000000b
<snip>
Thread 10 Crashed:
0 com.xojo.XojoFramework 0x016df6e8 0x161f000 + 788200
1 com.xojo.XojoFramework 0x016dba06 0x161f000 + 772614
2 com.xojo.XojoFramework 0x016da394 0x161f000 + 766868
3 com.xojo.XojoFramework 0x01779949 0x161f000 + 1419593
4 com.xojo.XojoFramework 0x01779993 0x161f000 + 1419667
5 com.xojo.XojoFramework 0x0168b5ed 0x161f000 + 443885
6 com.xojo.XojoFramework 0x01688baa 0x161f000 + 433066
7 com.xojo.XojoFramework 0x017797e6 0x161f000 + 1419238
8 com.xojo.XojoFramework 0x016e03da 0x161f000 + 791514
9 com.xojo.XojoFramework 0x016e0a2c 0x161f000 + 793132
10 com.xojo.XojoFramework 0x0176e744 RuntimeRaiseException + 297
11 com.xojo.XojoFramework 0x0171dce5 0x161f000 + 1043685
12 com.xojo.XojoFramework 0x017858bd RuntimeStackCheck + 73
13 <my app> 0x006f47c9 App.Event_UnhandledException%b%o<App>o<RuntimeException> + 1748
14 com.xojo.XojoFramework 0x016c0928 TryApplicationUnhandledException + 153
15 com.xojo.XojoFramework 0x017787f7 0x161f000 + 1415159
16 <my app> 0x006f493e App.Event_UnhandledException%b%o<App>o<RuntimeException> + 2121
17 com.xojo.XojoFramework 0x016c0928 TryApplicationUnhandledException + 153
18 com.xojo.XojoFramework 0x017787f7 0x161f000 + 1415159
19 <my app> 0x006f493e App.Event_UnhandledException%b%o<App>o<RuntimeException> + 2121
20 com.xojo.XojoFramework 0x016c0928 TryApplicationUnhandledException + 153
21 com.xojo.XojoFramework 0x017787f7 0x161f000 + 1415159
22 <my app> 0x006f493e App.Event_UnhandledException%b%o<App>o<RuntimeException> + 2121
23 com.xojo.XojoFramework 0x016c0928 TryApplicationUnhandledException + 153
24 com.xojo.XojoFramework 0x017787f7 0x161f000 + 1415159
25 <my app> 0x006f493e App.Event_UnhandledException%b%o<App>o<RuntimeException> + 2121
26 com.xojo.XojoFramework 0x016c0928 TryApplicationUnhandledException + 153
27 com.xojo.XojoFramework 0x017787f7 0x161f000 + 1415159
28 <my app> 0x006f493e App.Event_UnhandledException%b%o<App>o<RuntimeException> + 2121
29 com.xojo.XojoFramework 0x016c0928 TryApplicationUnhandledException + 153
30 com.xojo.XojoFramework 0x017787f7 0x161f000 + 1415159
31 <my app> 0x009ab809 cDevice.!the_eventHandler%%u4u4u4u4 + 1481
32 libxxxx.dylib 0x1359ac6b CFrameworkThread::sequenceMeasure(int) + 317
33 libxxxx.dylib 0x1359a9c9 CFrameworkThread::thread() + 289
34 libxxxx.dylib 0x1359b638 void* std::__1::__thread_proxy<std::__1::tuple<void (*)(CFrameworkThread*), CFrameworkThread*> >(void*) + 63
35 libsystem_pthread.dylib 0x9b4a2c25 _pthread_body + 138
36 libsystem_pthread.dylib 0x9b4a2b9b _pthread_start + 162
37 libsystem_pthread.dylib 0x9b49fe32 thread_start + 34
Norman_P
March 9, 2016, 8:18pm
6
libsystem_pthread.dylib
[quote=252251:@Steve Upton][quote]31 0x009ab809 cDevice.!the_eventHandler%%u4u4u4u4 + 1481)(CFrameworkThread ), CFrameworkThread*> >(void*) + 63
This is definitely a non-Xojo thread calling into Xojo code.
OK, thanks Joe, Norman and Christian.
I suspected as much but didn’t know the signs to watch for.
There may be a non callback-driven way of dealing with the SDK. I’ll try it out to see.
dispatch_async with dispatch_get_main_queue and you move the call to Xojo to the main thread.
@Christian Schmitz are you referring to how I might call the dylib from Xojo or how I might write it into a plug-in?
No, I mean in your C code you can use grand central dispatch to run it on the main thread.
ok, thanks. I’m not at the plugin stage yet but I’ll keep it in mind.
maybe you can ask the SDK provider to have an option that they make sure you get the callback on main thread.