[erlang-questions] OpenCL.framework cause my NIF library to crash

Alfredo Di Napoli alfredo.dinapoli@REDACTED
Sat Mar 17 17:12:26 CET 2012


So you think the problem may be caused by 64 bit?
I suppose that, in order to work, it need a 32 bit version of Erlang, isn't
it?
Bye
A.

Il giorno 17 marzo 2012 17:03, Tony Rogvall <tony@REDACTED> ha scritto:

> Update.
>
> running cl works on 32 bit emulator.
> So that is a great workaround, while poking around in the subject.
>
> /Tony
>
> On 16 mar 2012, at 15:41, Tony Rogvall wrote:
>
> Hi Dan!
>
> I think (and hope) that it is only dlopen that needs to be run from the
> main thread,
> is the undocumented feature accessible from the NIF's ?
>
> Otherwise what about having a special async thread you could run in the
> main thread?
>
> Apple still have not fixed poll ! Lets start a Facebook group ;-)
>
> /Tony
>
> On 16 mar 2012, at 12:09, Dan Gudmundsson wrote:
>
> That is a pain ...
>
> You can grab the main thread within erlang (undocumented ?)  because
> the gui must also be run from the
> main thread, which means that you can not combine OpenCL with wx (or esdl).
>
> Or is it only the dlopen call that must be run from that thread?
>
> Apple sometimes not so great..
>
> /Dan
>
> On Fri, Mar 16, 2012 at 11:34 AM, Tony Rogvall <tony@REDACTED> wrote:
>
> The problem seem to be dlopen, that it must be called from the main thread,
>
> this used to work. Googling around I can see other people have this
> problem,
>
> the work around for some projects is to run erlang as:
>
>
> erl -smp disable
>
>
> However, this is not possible with the cl binding since it require SMP(
>
> sending event messages from
>
> various threads )
>
> You can verify that the cl application loads ok with non smp, but then
> crash
>
> with
>
>
> enif_send: env==NULL on non-SMP VMAbort trap: 6
>
>
> as it should :-)
>
>
> Any OTP takers ? Sverker / Björn ?
>
>
> /Tony
>
>
>
>
>
>
> On 16 mar 2012, at 11:21, Alfredo Di Napoli wrote:
>
>
>
> On 16/mar/2012, at 11:10, Tony Rogvall wrote:
>
>
> I just tried it, and you are totally correct.
>
>
> The cl nif failed to load on R15B Darwin 11.3.0.
>
> What Erlang release and OS/release are you using ?
>
>
> /Tony
>
>
>
> Hi Tony, I'm on a Mac Os X Lion (so SDK 10.7) with the latest Erlang
>
> distribution R15B.
>
> I suspect this isn't a problem with your bindings, though, because I'm the
>
> same guy who asked you help about OpenCL binding with NIF via email :)
>
> I've also tried a brain-dead simple NIF application (a stupid app that
>
> performs a square of a number), compiling it from command line (so no Xcode
>
> involved :) )
>
> The NIF works fine, until I link ANY Mac OS Framework. In my example I've
>
> ONLY linked the AppKit.framework: bare in mind that actually the NIF does
>
> not uses it in any function call!
>
> The result? Abort trap!
>
>
> So I guess this could be a Erlang VM bug, related to Mac Os Frameworks
>
> dynamic linking process.
>
>
> Regards,
>
> Alfredo
>
>
>
>
>
> "Installing applications can lead to corruption over time. Applications
>
> gradually write over each other's libraries, partial upgrades occur, user
>
> and system errors happen, and minute changes may be unnoticeable and
>
> difficult to fix"
>
>
>
>
>
> _______________________________________________
>
> erlang-questions mailing list
>
> erlang-questions@REDACTED
>
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> "Installing applications can lead to corruption over time. Applications
> gradually write over each other's libraries, partial upgrades occur, user
> and system errors happen, and minute changes may be unnoticeable and
> difficult to fix"
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> "Installing applications can lead to corruption over time. Applications
> gradually write over each other's libraries, partial upgrades occur, user
> and system errors happen, and minute changes may be unnoticeable and
> difficult to fix"
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120317/027e1912/attachment.htm>


More information about the erlang-questions mailing list