C++ DAQmxStopTask issues

[LordNarf]

Greetings --

I am using a PCI-6025E board and a PCI-6503 board to manage simultaneous, on-demand digital, analog, and counter I/O on Windows 7 (x86/x64) and Windows XP (x86) systems.  (Analog and counter I/O applies only to the 6025E, naturally.)

I have converted an existing codebase from the Traditional/Legacy DAQ API to the DAQmx API, currently running with version 9.5.5.

At this point, I have all of the above functioning properly...with the exception of the 6025E's final cleanup operations on program shutdown.

Our main application is written in Java, with our DAQmx code controlling the 6025E residing in its own native cpp class, which sets up in its constructor one dedicated DAQmx task for each of the following: digital input, digital output, analog input, analog output, and counter functions.

I am having two problems that manifest in the class's destructor, where I'm clearing the tasks:

1) The DAQmxClearTask calls for the digital I/O tasks and analog output task work properly, but when DAQmxClearTask (or StopTask, for that matter) is called with the analog input task, the application throws a C++ R6025 -Pure virtual function call error.

To clarify somewhat, this task organizes multiple DAQmxCreateAIVoltageChan lines.  In my efforts to debug this, I have determined that as soon as the task contains at least one AI voltage channel, it will be subject to this error.  During program execution, the task reads its analog inputs as it should with no errors or other issues, until it is stopped/cleared.

2) In most circumstances, the counter task is stopped/cleared properly.  If, however, the class destructor runs while a counter is running a pulse train, any Stop/ClearTask call made with that task causes the program to hang indefinitely -- no errors, and the application's DOS window can be manually closed with no adverse effects, but the program execution (exiting) will not continue from that point.

Concerning both issues, I can simply omit the calls to clear those tasks and the program will terminate gracefully...but I'm not certain if this would produce any other undesirable effects, and I'd rather resolve them outright, if I can.

Are there any known solutions to the above behavior?

If more input is required, please ask -- I'd appreciate any feedback at this point.

[Eric-E]

Hello,
Although I'm unfamiliar with this error I wanted to give a quick link related to this error that might help you out:

http://www.artima.com/cppsource/pure_virtual.html

It seems that this error is also caused by a device not properly installed although I don't think this is your issue:

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

[LordNarf]

@Eric-E:

Thank you for that first link -- it was an interesting read.

Unfortunately, I'm not sure it applies to my situation.  Our DAQ class isn't written in a polymorphic context, and tagging any/all of its functions as virtual (or not) does seem to affect the behavior of the bug I'm seeing.

Regarding the second link, I believe you are correct: this issue is present across multiple installations, on multiple platforms.

One little sanity check that I feel I ought to point out: nothing (in our code, at least) stops, clears, or deletes the AI task prior to the class destructor.

[LordNarf]

Apologies for the double-post -- does this board have an edit functionality?

Minor correction to my earlier post:

"tagging any/all of its functions as virtual (or not) does seem to affect the behavior of the bug I'm seeing"

should read

"tagging any/all of its functions as virtual (or not) does *not* seem to affect the behavior of the bug I'm seeing".

[Eric-E]

Hmm.. have you tried to run any example code? This is how I would approach the issue because I have never worked with Java and am not sure what is causing the error. 

[LordNarf]

Update:

I've reached a resolution to my issues that I am comfortable with, for now.

I have moved the problematic DAQmxClearTask calls (again, for the analog input and counters only) to a support method (still within the native DAQ class) that is called on program shutdown, but before the DAQ class's destructor runs.  This results in a perfectly clean shutdown and deletion/deallocation of all NI-related infrastructure in our codebase.

@Eric-E:

I have not compiled and run NI's prepackaged C examples, but at this point I don't think it would be very helpful to do so.  The issue specifically manifested when the problematic tasks were cleared in the containing class's destructor.

At any rate, thank you for sticking with this thread!

While I have resolved the problems that I've reported here, I would still appreciate any kind of input or even speculation as to the nature of the issue, as my solution was a simple workaround -- I still do not understand the cause of the core issue.

[Brad_K]

I think the purecall is coming from one of the DAQmx DLLs, not your JNI DLL. Could you post a stack trace or minidump to identify where the purecall is coming from? Likewise for the hang.

---

@LordNarf wrote:

While I have resolved the problems that I've reported here, I would still appreciate any kind of input or even speculation as to the nature of the issue, as my solution was a simple workaround -- I still do not understand the cause of the core issue.

---

Are you calling into DAQmx from DllMain() or from the constructor/destructor of a global/static C++ object? If so, the purecall might be due to DAQmx calling into a global C++ object that its DllMain() has already destructed, and the hang might be a deadlock on the Windows DLL loader lock (since DAQmx API functions may load/unload other DLLs).

Brad

[lachinaj]

Hi,

I'm the same problem.

When my program run into Visual Studio 2012 all work correctly, but out of Visaul Studio, I am a "pure virtual function call" !!!

This is the code (c#) of my stop function:

public void Stop()

{

   try

   {

      task.Stop();
      task.Dispose();                 // pure virtual function call

   }

   catch(Exception ex)

   {

       ...

   }

}

The error is on the Dispose, if I delete this line, I'm not the error but it's not possible to create another task with same line.

Do you have a solution?

Thanks

[Joel-I]

Hi lachinaj,

You may get better traffice by creating a new thread.

Regards,