[erlang-questions] NIF+device problem moving R18->R19 / Mac 10.11->10.12
Igor Clark
igor.clark@REDACTED
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 <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/20170421/c9d3fe08/attachment.htm>
More information about the erlang-questions
mailing list