EXC_BAD_ACCESS when calling any DAQmxBase related functions

[Astat]

Hi All,

In short:

I am trying to use the NI-DAQmx base framework from a C program written with XCode, targetting both Snow Leopard and Lion. 

The program compiles and runs, but any call to any daqmxbase related function leads to an EXC_BAD_ACCESS error.

DAQmxbase version is 3.4.5 AUG 2011

More details:

The program I am writing already uses with success the NI488 framework. So, I guess that the integration of the framework to the project should be OK. I have added nidaqmxbasevl.framework and nidaqmxbase.framework to the project as well as the header file 

/Applications/National Instruments/NI-DAQmx Base/includes/NIDAQmxBase.h

However, when adding the NI488 framework, it was immediately available in the framework list, whereas I had to manually navigate to the nidaq-related framework in order to add it to the project. The error could be there, I suppose (I did add the .framework folder). But then, I still don't understand why  nidaqmxbase and nidaqmxbasevl don't show up as framework...

Does anyone know how to silve this issue ?

---

Edit: here is an example of code generating a EXC_BAD_ACCESS signal

char taskName[] = "theTaskName";
TaskHandle taskHandle = 0;
DAQmxBaseLoadTask(taskName, &taskHandle);

[sth]

After a lot of communication, the problem is that you can not call into the NI-DAQmx Base framework from a C program.

See the following thread for more info:

http://forums.ni.com/t5/Multifunction-DAQ/DAQmxBaseCreateTask-gt-Bus-Error-10/m-p/1763708?requireLog...

One thing to note that NI-DAQmx base seems to be working in a beta fashon for LabVIEW calls under Mac OS X 10.7 (Lion)

http://digital.ni.com/public.nsf/allkb/F092760FFB971DFA862578B0006458A5

I believe installing the latest NI-VISA and NI-488.2 will install 64 bit compatible kernel extensions.  But Katie L states

"The behavior you are seeing is a known issue and R&D is currently working on it. At this time, the LabVIEW interface works with Lion (hence the reason Isdaq and data logger work), but the C interface does not. You will need to either use the LabVIEW interface or use 10.6 as I mentioned earlier until the DAQmx base is officially supported on Lion"

[JoeFriedchicken]

---

sth wrote:

I believe installing the latest NI-VISA and NI-488.2 will install 64 bit compatible kernel extensions.  But Katie L states:

"The behavior you are seeing is a known issue and R&D is currently working on it. At this time, the LabVIEW interface works with Lion (hence the reason Isdaq and data logger work), but the C interface does not. You will need to either use the LabVIEW interface or use 10.6 as I mentioned earlier until the DAQmx base is officially supported on Lion"

---

There has been some investigation done on this, and the 64-bit kernel is not a factor here. Indeed, if you boot a machine with Lion into 32-bit mode, a LabVIEW-built framework (or any other program that links agains a LabVIEW-built framework, like the DAQmx Base C interface) will still report this error.

The underlying issue is OS security and was first noticed in Linux: LabVIEW-built command line executables would also fail, but Linux was more forthright to the user about what was happening -- memory execution -- and provided an immediate GUI for exempting this behavior. Lion introduced many of the same safeguards that SELinux did years ago, and other folks have been affected as well [1], but Lion was much more quiet about it. The work around for now is to add the flag -allow_heap_execute [2] to the linker options.

[1] MacPorts on Lion (common issues, fixes, and workarounds)

http://lists.macosforge.org/pipermail/macports-dev/2011-July/015263.html

[2] ld(1) Mac OS X Developer Tools Manual Page

http://developer.apple.com/library/mac/#documentation/Darwin/Reference/Manpages/man1/ld.1.html

[sth]

---

@JoeFriedchicken wrote:

---

The work around for now is to add the flag -allow_heap_execute [2] to the linker options.

---

Joe,

Thanks for the clarification.  This is different than I was thinking but the problem is the same.  A code pointer is pointing to a data space area for execution.  This usually means something bad has happened.

Ack, so this turns off the security of separating data and code.  Thus anything that can trick the application to execute on the heap is a vulnerability.  This hardware protection has been available for memory management chips since the 90s and I always thought it was taking way too long for Apple and other OS vendors to adopt such memory management techniques in the name of security.

So merely turning off this security feature does allow the programs to compile and run.  Whether this is a good idea or not is another question.  I hope that NI will be coming out with a real fix and this work around will not be needed in the future. 

[JoeFriedchicken]

---

sth wrote:

So merely turning off this security feature does allow the programs to compile and run.  Whether this is a good idea or not is another question.  I hope that NI will be coming out with a real fix and this work around will not be needed in the future.

---

Adding the linker flag on Lion gives the user an executable-level granularity -- other programs will still crash if they attemp to execute data. The SELinux configuration, as presented in GUI form, turns it off for the whole system. It takes a lot more effort to get it scoped to a single executable.

The newer LabVIEW for Linux run-time engines (I believe beginning with LabVIEW 2010, but I'm not certain) are better citizens and compile executables such that they only run code in the .text segment of the executable. DAQmx Base 3.4 used that version of the run-time engine, but then the run time performance suffered so much that people thought their programs were hanging [1]. So for DAQmx Base 3.4.5 (the latest available at the time of this post [2]), we reverted back to the LabVIEW 8.2 run-time engine to restore program speed.

Coming back to Lion, if you compile a DAQmx Base (version 3.4.5) C example and enable an executable heap, the program will still crash, but this time on exit: VISA has a race condition when it leaves memory and most of the time something is deleted before it expects to be.

[1] NI Linux Users Group: program locks on DAQmxBaseCreateTask

https://decibel.ni.com/content/thread/5332?tstart=0

[2] NI Drivers and Updates: DAQmx Base releases

http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/en/pg/1/ps/20/sn/catnav:du,n8:3478,ssna...

[sth]

---

@JoeFriedchicken wrote:

Adding the linker flag on Lion gives the user an executable-level granularity -- other programs will still crash if they attemp to execute data. The SELinux configuration, as presented in GUI form, turns it off for the whole system. It takes a lot more effort to get it scoped to a single executable.

The newer LabVIEW for Linux run-time engines (I believe beginning with LabVIEW 2010, but I'm not certain) are better citizens and compile executables such that they only run code in the .text segment of the executable. DAQmx Base 3.4 used that version of the run-time engine, but then the run time performance suffered so much that people thought their programs were hanging [1]. So for DAQmx Base 3.4.5 (the latest available at the time of this post [2]), we reverted back to the LabVIEW 8.2 run-time engine to restore program speed.

---

Joe,

Since you are so full of great info here.  I have more questions!  I realize that that linker is only turning it off for that executable.  Interesting that each executable can flag the system to create this security disabling feature.

Is the performance hit just with the DAQmx base that triggered some "unexpected feature" of the newer run time engines or is it something that because they separate .text and .data segments  that they are not as efficient?

Do the newer run time engines also implement data segments that are read only vs. read/write?  IIRC they were .dss segments and the normal .data segments.  That was also a great leap forward in compiler technology.  In the very old FORTRAN one could set the value of the constant "1" to a different value.  And if you hid that statement well you could really create obfuscatory code!  Or broken code when you typed a "1=0" and not an "I=0" statement!  From that point on, every 1 in the program would have  value of 0.  Putting constants in read only memory would cause this to crash with a similar exception error.

[JoeFriedchicken]

---

sth wrote:

Is the performance hit just with the DAQmx base that triggered some "unexpected feature" of the newer run time engines or is it something that because they separate .text and .data segments  that they are not as efficient?

---

The performance degradation is unrelated to where the run-time engine places code. Rather, LabVIEW changed some of its internal storage and algorithms for accessing VIs, and DAQmx Base magnified those changes. When characterizing this for LabVIEW, I demonstrated that even small libraries were slower to load.

---

sth wrote:

Do the newer run time engines also implement data segments that are read only vs. read/write?  IIRC they were .dss segments and the normal .data segments.

---

I don't know this one 😉 I think it would be fairly easy to make a guess though -- place a few string constants in a VI and see where they show up an ELF binary.