NIDAQmxBase calls on MAC OSX crashes UI application

[whemdan]

It appears that using the NIDAQmxBase drivers’ v14.0 on a MAC OSX causes GUI applications to crash.

A simplified version of a GUI reproducing this issue is attached.

Essentially the problem seems to be that NIDAQmxBase driver needs to be called on the main thread before any initialization of the GUI application. This is a severe limitation because the initialization of the GUI application requires the setting of some custom app delegates. Unfortunately setting up the custom app delegates in the UI initialization and then calling the driver leads to a segmentation violation crash in NIDAQmxBase that also brings down the calling application.

QUESTION 1: Is it possible to call the NIDAQmxBase library without needing to run it on the main thread (i.e. can I make all my calls from a secondary thread)?

QUESTION 2: We also noticed that calls to the NIDAQmxBase library before GUI initialization changes the app delegates. Is there any workaround for this?

A full GUI application and project are attached to reproduce this bug (Note, we removed the nidaqmxbase.framework and nidaqmxbaselv.framework from the project due to size limitation on the upload. You will need to re-add those files from the /Library/Frameworks/ directory to the project to prevent linker errors).

Below are a few code snippets where the issues are arising.

MAIN.M: This is the main file for the GUI application. (See ISSUE 1, in code below)

//
//  main.m
//  NI_Library_Crash
//

#import <Cocoa/Cocoa.h>
#import "Utility.h"
int main(int argc, const char * argv[]) {
    NSLog(@"At first, App delegate: %@",[NSApp delegate]);

    // ISSUE 1:
    // Calling the NI Libraries before starting up the GUI is an unacceptable work around as it blocks the main thread
    // Additionally, my application has a number of customizations based on the application delegate. These appear to be stomped on by calling the following function on the main thread.
    // Please see ISSUE 2 in AppDelegate.m

    // callNiLibs();
    // NSLog(@"After calling NI Libraries, App delegate: %@",[NSApp delegate]);
    return NSApplicationMain(argc, argv);
}

APPDELEGATE.M: This file handles the button click for the UI. (See ISSUE 2 in the code below.)

//
//  AppDelegate.m
//  NI_Library_Crash
//

#import "AppDelegate.h"
#import "Utility.h"
@interface AppDelegate ()

@property (weak) IBOutlet NSWindow *window;
@end

@implementation AppDelegate

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
    // Insert code here to initialize your application
}

- (void)applicationWillTerminate:(NSNotification *)aNotification {
    // Insert code here to tear down your application
}

// Button click callback
- (IBAction)callNILibraries:(id)sender {
    // Attempt to get NI device number
    // ISSUE 2:
    // Calling this function causes the Cocoa application to crash
    callNiLibs();
}
@end

Regards,

    Wael Hemdan

    MathWorks

[WillMck]

whemdan, 

I'll have to look into your questions a bit further. 

To start, what version of OSX are you developing on? Also, what SDE are you programming with? 

[whemdan]

Hi,

We developed this on OS X 10.9.0 Mavericks.
XCode version I believe was XCode 5.1.1.

Version of the NI Driver: NI-DAQmxBase 14.0

There is another version which was developed on OS X 10.9.5 with XCode 6.1.1 which had the same results.

Thanks,

   Wael Hemdan

   MathWorks

[WillMck]

Whemdan,

I've looked into your questions a bit further. The DAQmx API is single-threaded by default and wherever the task is initialized is the thread in which the function will execute. We recommend using a single thread for DAQmx calls. It is possible to get multi-threading using DAQmx when using the asynchronous call function. However, if you can make the calls synchronous, that would help you limit the DAQmx functions to a single thread. How the threads in your C application are managed will be up to you, but in theory you should be able to call into the library in another thread outside the main thread. 

What parameters of the app delegates change when calling the DAQmxBase Library? 

[whemdan]

Hi Will,

In the code that we sent you, we are infact calling the NIDAQmxBase from only one thread (this is not the main thread), and this is crashing. Running the attached code, launches a window with a single button. Clicking on that button, fires a callback function (AppDelegate.m, line 28: callNiLibs) which calls the NIDAQmxBase library to retreive the device serial number (Utility.mm, line 10: DAQmxBaseGetDevSerialNum). The crash occurs after stepping over this line.

With regards to the app delatage parameters,we are not changing any of them - we're using the defaults. It appears that calling the NIDAQmxBase library changes the 'delegate' property of the NSApp. Please uncomment lines 16 and 17 of the attached main.m to see this change. Uncommenting these 2 lines causes the call to happen from the main thread and the crash goes away - however this is not an acceptable workaround as described in our original post.

Thanks,

   Wael Hemdan

   MathWorks

[WillMck]

Whemdan, 

Unfortunately, I don't have an immediate solution for this. I will have bring this up to NI R&D to see if something this low-level is expected behavior. When any next steps are given, I will post them here. If you make progress in the meantime and would like to post for the benefit of the community, please do. 

[whemdan]

Hi,

Do we have any updates from R&D on this yet?

Also note that there are other users who seem to be running into this same problem:

http://forums.ni.com/t5/facebookforums/facebooksingletopicpage/facebook-app/417075545007603/message-...

 Thanks,

   - Wael Hemdan

     MathWorks

[WillMck]

Unfortunately, I don’t have any updates at this point and am waiting to hear back from the developers. I’ve put in a request for our research team to look into the specific content of this forum post more closely.

Thank you for making us aware that other users are running into similar issues. If the issue is indeed a bug with the DAQmxbase driver, it may be some time before a patch is released. We’ll attempt to find a workaround in the meantime.  

[whemdan]

Hi Will,

Thanks for the reply. I understand it may be some time before we get a fix. In the meantime, can we get a CAR# to track this issue?

Thanks,

   Wael Hemdan

   MathWorks

[WillMck]

We don't currently have a CAR number for the issue because we haven't verified that this issue is directly tied to a bug in the DAQmxbase driver at this point. I can't make promises on a timeline because National Instruments does not officially support programming the the Xcode development environment (disclaimer referenced in the following KB). 

Using the NI-DAQmx Base C API in Xcode - http://digital.ni.com/public.nsf/allkb/86402BA624A44543862571000001D8BF

I've filed a request internally to have R&D look into the issue and if a CAR is indeed produced from the inquiry we can try to post a potential workaround and CAR number on the forum.