[erlang-questions] more than 2 nifs in an app. total screw up?

Vans S vans_163@REDACTED
Sat Mar 10 05:57:58 CET 2018

Just windows and OSX I would assume. On linux I had to take a different multiprocess approach. 

    On Tuesday, March 6, 2018 12:46 AM, Valentin Micic <v@REDACTED> wrote:

 So… is the same fix, as suggested by Mr Hoguin for OSX, relevant to all three environments then?
On 05 Mar 2018, at 4:24 PM, Vans S wrote:

I realize my mistake right after sending out.  Indeed its related to this, on Windows and OSX you can load two different versions of same lib just fine. On Linux, they symbols will be taken from first loaded lib, and second loaded lib will call symbols from the first loaded lib if the signatures are the same! This was the reason I had erroneous behavior and random segfaults. 

    On Sunday, March 4, 2018 4:30 AM, Loïc Hoguin <essen@REDACTED> wrote:

 If that's on OSX you need the -dynamiclib flag, otherwise functions with 
the same name will get overwritten when the second library is loaded, 
and this can result in this kind of behavior.

On 03/04/2018 04:20 AM, Vans S wrote:
> When I load more than 2 nifs in an app, I get total undefined defined 
> behavior depending which nif loaded first. Like everything is totally 
> messed up.
> Example:
> LD_PRELOAD="/nif1,so /nif2.so" rebar3 shell
> nif1 works, nif2 is totally messed ,and randomly segfaults or gives 
> errorneous results.
> LD_PRELOAD="/nif2,so /nif1.so" rebar3 shell
> Now nif2 works, and nif1 is erroneous.
> Iv noticed this behavior before I recall, but now its resulted in so 
> much frustration. Things were crashing in C++ boost side like
> mystruct v = boost::value_initialized<decltype(v)>();
> Crash here with "terminate called after throwing an instance of 
> 'std::bad_alloc'". Switch the order of the nifs and it works fine.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

Loïc Hoguin

erlang-questions mailing list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180310/ac77bdde/attachment.htm>

More information about the erlang-questions mailing list