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

Igor Clark <>
Fri Apr 21 01:12:20 CEST 2017


Quick update - looks like it's not the hardware API at all, and I guess 
not erlang either, but Objective-C/Foundation stuff related to how I was 
initialising CFStringRef values whose addresses I passed to the API 
call. I was using a CFSTR macro that I took from an Apple code sample; 
now I'm using a CFString function to do it and it's working fine across 
the erlang & OS versions.

I'm a bit baffled as to why the macro was working at all on R18, and why 
it still works in the minimal C program version, as it looks to me like 
it returns an immutable string ref; maybe it shouldn't work, but like I 
say, I took it from an Apple sample. I plan to look into that a bit more 
deeply.

I'm also pretty baffled as to why the different erlang & OS/compiler 
versions made this manifest, when it wasn't previously - but regardless, 
taking it out seems to have side-stepped the problem.

Thanks everyone,

best,
Igor

On 19/04/2017 13:33, Igor Clark wrote:
> 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 < 
>> <mailto:>> 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
>>>     < <mailto:>> 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:* 
>>>         <mailto:>
>>>         <
>>>         <mailto:>> on behalf of
>>>         Igor Clark < <mailto:>>
>>>         *Sent:* Monday, April 17, 2017 4:38:11 PM
>>>         *To:* 
>>>         <mailto:>
>>>         *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
>>>          <mailto:>
>>>         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
>>>          <mailto:>
>>>         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/20170421/c9d3fe08/attachment.html>


More information about the erlang-questions mailing list