[erlang-questions] OS X Trace/BPT trap error loading linked in driver

[Paul Davis]

On Tue, Apr 6, 2010 at 1:11 PM, David Rowe <david.rowe@REDACTED> wrote:
> I am writing a linked-in driver on OS X. The driver relies on some of the OS
> X API "framework" libraries. The problem is that when I call
> erl_ddll:load_driver, there is a Trace/BPT trap error and everything dies.
>
> If I look at the crash report in Console I see this:
>
> Exception Type:  EXC_BREAKPOINT (SIGTRAP)
> Exception Codes: 0x0000000000000002, 0x0000000000000000
> Crashed Thread:  5
>
> Thread 5 Crashed:
> 0   com.apple.CoreFoundation          0x00007fff867811c0 __CFInitialize +
> 1808
> 1   dyld                              0x00007fff5fc0d5ce
> ImageLoaderMachO::doImageInit(ImageLoader::LinkContext const&) + 138
> 2   dyld                              0x00007fff5fc0d607
> ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 27
> 3   dyld                              0x00007fff5fc0bcec
> ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
> unsigned int) + 236
> 4   dyld                              0x00007fff5fc0bc9d
> ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
> unsigned int) + 157
> 5   dyld                              0x00007fff5fc0bc9d
> ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
> unsigned int) + 157
> 6   dyld                              0x00007fff5fc0bc9d
> ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
> unsigned int) + 157
> 7   dyld                              0x00007fff5fc0bda6
> ImageLoader::runInitializers(ImageLoader::LinkContext const&) + 58
> 8   dyld                              0x00007fff5fc08fbb dlopen + 573
> 9   libSystem.B.dylib                 0x00007fff831a7720 dlopen + 61
> 10  beam.smp                          0x000000001011c4ef
> erts_sys_ddll_open_noext + 47 (erl_unix_sys_ddll.c:129)
>
>
> I'm pretty sure that the Exception is being caused by this line in the
> __CFInitialize function:
>
> if (!pthread_main_np()) HALT;    // CoreFoundation must be initialized on
> the main thread
>
>
> So my question is, does anyone know how to get Erlang to load my driver on
> its main thread? Or is there any kind of workaround? The only options I can
> see at the moment are rewriting the driver as a "c node" (possibly too slow)
> or moving to LinuxŠ
>
> Thanks,
>
> David Rowe
>

David,

I ran into that same issue when attempting to link against
Spidermonkey in a driver. At the time I found another report [1] that
found exactly what you pointed out, loading CoreFoundation halts the
process when it wasn't initialized on the main thread. In my case I
could get away with just making sure that nothing touched the
CoreFoundation classes, while in your case that doesn't appear to be
possible. The only thing I could think of would be to patch Erlang to
do whatever CoreFoundation initializations is needed.

HTH,
Paul Davis

[1] http://openradar.appspot.com/7209349