NIF+device problem moving R18->R19 / Mac 10.11->10.12

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

NIF+device problem moving R18->R19 / Mac 10.11->10.12

Igor Clark
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NIF+device problem moving R18->R19 / Mac 10.11->10.12

Paul Fisher
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.



From: [hidden email] <[hidden email]> on behalf of Igor Clark <[hidden email]>
Sent: Monday, April 17, 2017 4:38:11 PM
To: [hidden email]
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
[hidden email]
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NIF+device problem moving R18->R19 / Mac 10.11->10.12

Daniel Goertzen-3
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 <[hidden email]> 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.



From: [hidden email] <[hidden email]> on behalf of Igor Clark <[hidden email]>
Sent: Monday, April 17, 2017 4:38:11 PM
To: [hidden email]
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
[hidden email]
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NIF+device problem moving R18->R19 / Mac 10.11->10.12

Igor Clark
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 <[hidden email]> 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.



From: [hidden email] <[hidden email]> on behalf of Igor Clark <[hidden email]>
Sent: Monday, April 17, 2017 4:38:11 PM
To: [hidden email]
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
[hidden email]
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NIF+device problem moving R18->R19 / Mac 10.11->10.12

Igor Clark
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 <[hidden email]> 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 <[hidden email]> 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.



From: [hidden email] <[hidden email]> on behalf of Igor Clark <[hidden email]>
Sent: Monday, April 17, 2017 4:38:11 PM
To: [hidden email]
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
[hidden email]
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NIF+device problem moving R18->R19 / Mac 10.11->10.12

Igor Clark
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 <[hidden email]> 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 <[hidden email]> 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.



From: [hidden email] <[hidden email]> on behalf of Igor Clark <[hidden email]>
Sent: Monday, April 17, 2017 4:38:11 PM
To: [hidden email]
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
[hidden email]
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions




_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NIF+device problem moving R18->R19 / Mac 10.11->10.12

Igor Clark
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 <[hidden email]> 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 <[hidden email]> 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.



From: [hidden email] <[hidden email]> on behalf of Igor Clark <[hidden email]>
Sent: Monday, April 17, 2017 4:38:11 PM
To: [hidden email]
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
[hidden email]
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions





_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Loading...