[erlang-questions] NIF+device problem moving R18->R19 / Mac 10.11->10.12
Tue Apr 18 04:47:11 CEST 2017
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@REDACTED> on behalf of Igor Clark <
> *Sent:* Monday, April 17, 2017 4:38:11 PM
> *To:* erlang-questions@REDACTED
> *Subject:* [erlang-questions] NIF+device problem moving R18->R19 / Mac
> 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,
> erlang-questions mailing list
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions