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

[Dan Gudmundsson]

I don't know, wxWidgets-2.8 uses carbon, which sets the 32 bit requirement.
I havn't tried anything else.

Erlang calls the driver from a scheduler thread, if the "main" thread
is the first
started thread then it will not be called from there, that thread is
used for other things.

/Dan

2010/4/7 David Rowe <david.rowe@REDACTED>:
> But does it though? I can't tell: I'm using 64-bit Snow Leopard, so I get
> "Can not combine 64bits erlang with wxWidgets on MacOSX" when I compile
> R13B04.
>
> I might well be wrong, but if I'm right I can't see anyway around that
> pthread_main_np() call. It will always return 0, because Erlang will always
> load a linked-in driver on a thread other than the main thread, won't it?
>
> David
>
>
>
>
> On 06/04/2010 23:40, "Dan Gudmundsson" <dangud@REDACTED> wrote:
>
>> 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
>>>
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>