[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.


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