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

[David Rowe]

Thanks everyone. I think the Open Radar report is pretty conclusive :-(

David



On 07/04/2010 16:41, "Paul Davis" <paul.joseph.davis@REDACTED> wrote:

> 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
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>