[erlang-questions] NIF+device problem moving R18->R19 / Mac 10.11->10.12
Igor Clark
igor.clark@REDACTED
Wed Apr 19 14:33:09 CEST 2017
Hi folks, just checking in, I wonder if anyone has any further thoughts
about this?
To re-state: the identical Mac OS C API call inside a NIF succeeds
(returns a valid string property) on R18/El Capitan, fails (returns
null) inside the same NIF on R19/El Capitan & R18/R19/Sierra, yet
succeeds in a minimal C program on both El Capitan (clang/LLVM 8.0.0)
and Sierra (clang/LLVM 8.1.0). In all cases this happens regardless of
whether the C API call is made inside the main thread or a separate thread.
Would be really grateful for any suggestions, as this is way lower-level
than I'm familiar with - happy to dig around further, but a bit lost
where to look next.
Thanks!
Igor
On 18/04/2017 07:54, Igor Clark wrote:
> 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
> <mailto: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 <mailto: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
>> <mailto:erlang-questions-bounces@REDACTED>
>> <erlang-questions-bounces@REDACTED
>> <mailto:erlang-questions-bounces@REDACTED>> on behalf of
>> Igor Clark <igor.clark@REDACTED <mailto:igor.clark@REDACTED>>
>> *Sent:* Monday, April 17, 2017 4:38:11 PM
>> *To:* erlang-questions@REDACTED
>> <mailto: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 <mailto: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=VYIypVbNEBkrDndUBzmlPhRtnzb4ZWIKbuytw-ZNFsQ&s=jm04c9Iw58-WmaHYaGFw-a9XQ3sFl2wqkf7RhdBDC6E&e=
>> <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=VYIypVbNEBkrDndUBzmlPhRtnzb4ZWIKbuytw-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 <mailto:erlang-questions@REDACTED>
>> http://erlang.org/mailman/listinfo/erlang-questions
>> <http://erlang.org/mailman/listinfo/erlang-questions>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170419/87588750/attachment.htm>
More information about the erlang-questions
mailing list