[erlang-questions] OS X Trace/BPT trap error loading linked in driver
Dan Gudmundsson
dangud@REDACTED
Wed Apr 7 00:40:32 CEST 2010
It should work anyway, it does for wx, see how I initialize the graphics in wx.
It complains but it works.
/Dan
On Tue, Apr 6, 2010 at 7: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
>
More information about the erlang-questions
mailing list