[erlang-questions] NIF+device problem moving R18->R19 / Mac 10.11->10.12

[Igor Clark]

Sorry, to be clearer, that should have read "when run in a separate thread
in the NIF using enif_thread_create(), the API call succeeds under R18 on
El Capitan, fails under R19 on El Capitan, and fails under R18 and R19 on
Sierra".

On Tue, Apr 18, 2017 at 7:52 AM, Igor Clark <igor.clark@REDACTED> wrote:

> Thanks Paul and Daniel,
>
> Just tested this: the exact same thing happens with threads as without.
> The API call succeeds when run in a separate thread in the minimal C
> program using pthread_create(), on both El Capitan and Sierra; when run in
> a separate thread in the NIF using enif_thread_create(), the API call
> succeeds under R18 on El Capitan and fails under R19.
>
> (My NIF code hasn't been explicitly creating or using any threads at all
> until now, if that makes any difference.)
>
> Does that give any further clues?
>
> Cheers,
> Igor
>
>
> On 18/04/2017 03:47, Daniel Goertzen wrote:
>
> Following Paul's idea, what happens in both the NIF and your minimal C
> program if you first launch a new thread and call the API from there?
>
> On Mon, Apr 17, 2017 at 5:52 PM Fisher, Paul <pfisher@REDACTED>
> wrote:
>
>> Complete wild guess, but is there a difference in nif initialization
>> running off the main thread in non-working version? This would be a problem
>> for some low-level Mach related things. Not near laptop to look through the
>> code to see if that changed.
>>
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> ------------------------------
>> *From:* erlang-questions-bounces@REDACTED <erlang-questions-bounces@
>> erlang.org> on behalf of Igor Clark <igor.clark@REDACTED>
>> *Sent:* Monday, April 17, 2017 4:38:11 PM
>> *To:* erlang-questions@REDACTED
>> *Subject:* [erlang-questions] NIF+device problem moving R18->R19 / Mac
>> 10.11->10.12
>>
>> Hi all,
>>
>> I'm having problems updating a NIF to work correctly with R19 and/or
>> MacOS Sierra (10.12). The NIF uses Mac OS C API calls to talk to some
>> hardware. It's been working just fine with R18 on El Capitan, but it
>> fails in a manner I don't understand when I trying to run it on R19 or
>> Sierra. I'm pretty baffled as to what's going on, and wonder if any of
>> the following might ring bells or set off a spider-sense for anyone here?
>>
>> - The code continues to work 100% as expected on R18 / Mac OS El Capitan
>> (10.11), as it has for the last year or so.
>>
>> - On R19 on El Capitan, 99% of the C code works as before, but one
>> particular MacOS C API call fails unexpectedly. It doesn't crash or
>> cause errors directly, but it returns null instead of a valid value as
>> before. There are no build errors or warnings. (I'm using 'pc' plugin
>> version 1.5.0 with rebar3). Other MacOS API calls talking to the same
>> hardware work as expected, sending correct commands, getting the
>> hardware to carry out operations as expected and returning expected
>> values, without any problems.
>>
>> - On both R18 & R19 on Sierra, exactly the same problem occurs as above
>> in R19 on El Capitan.
>>
>> - If I make the failing/null-returning OS API call in a plain,
>> simple-as-possible C file compiled with gcc (Apple LLVM/clang), it works
>> as expected, *on both OS versions*.
>>
>> - If I paste that same simple-as-possible C code verbatim into the NIF,
>> as the first line in the load() function, and run it on R18/El Capitan,
>> it continues to work as expected.
>>
>> - If I then try to run that identical pasted-verbatim NIF code with no
>> changes on R18/Sierra or on R19 & either OS version, this one particular
>> function call fails, as above.
>>
>> I realise it could be many things, and my initial thought was that it
>> must be the OS change or even the hardware failing - but the hardware
>> and C API call continue to work just fine on both OS versions when the
>> NIF stuff is taken out of the picture, and on El Capitan, the
>> previously-not-happening problem reliably (and only) starts happening
>> when I switch from R18 to R19.
>>
>> Did anything change between R18 and R19 that might somehow make some,
>> but not all, external C function calls fail on El Capitan/clang 8.0.0?
>> And could that be something that also makes the same thing happen on
>> both R18 and R19 under Sierra/clang 8.1.0? Could it perhaps be something
>> do with the port compiler & LD/CXX flags?
>>
>> Any ideas as to where else I could look to try to track this down, or
>> what might be causing this?
>>
>> (BTW, I'm using homebrew erlang, and I've tried all the above with
>> versions 18.1, 18.3, 19.0.2 and 19.3 on both OS versions. The gcc/clang
>> version on El Capitan is from Xcode 8.1, "Apple LLVM version 8.0.0
>> (clang-800.0.42.1)". On Sierra it's from Xcode 8.3.1, "Apple LLVM
>> version 8.1.0 (clang-802.0.41)" - but as above, the plain/non-NIF C code
>> works perfectly and identically on both versions.)
>>
>> Thanks very much,
>> Igor
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__erlang.
>> org_mailman_listinfo_erlang-2Dquestions&d=DwICAg&c=L_
>> h2OePR2UWWefmqrezxOsP9Uqw55rRfX5bRtw9S4KY&r=PevFox_7LK44ZV_
>> jlS5jRM2WItKtsHV4zN_CrbdT2aM&m=VYIypVbNEBkrDndUBzmlPhRtnzb4ZW
>> IKbuytw-ZNFsQ&s=jm04c9Iw58-WmaHYaGFw-a9XQ3sFl2wqkf7RhdBDC6E&e=
>> Confidentiality Notice | This email and any included attachments may be
>> privileged, confidential and/or otherwise protected from disclosure. Access
>> to this email by anyone other than the intended recipient is unauthorized.
>> If you believe you have received this email in error, please contact the
>> sender immediately and delete all copies. If you are not the intended
>> recipient, you are notified that disclosing, copying, distributing or
>> taking any action in reliance on the contents of this information is
>> strictly prohibited.
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170418/6d35c667/attachment.htm>