OS X Trace/BPT trap error loading linked in driver

David Rowe david.rowe@REDACTED
Tue Apr 6 19:11:22 CEST 2010


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