CVI2009 The program has caused a 'General Protection' fault

[Gaus]

Hi,

After installing CVI2009 on the development machine, I got the message "The program has caused a 'General Protection' fault" for a specific application compiled with CVI2009 and application error for the applications compiled with earlier version of Labwindows.

Debug mode shows the failure at GetUserEvent () or ProcessSystemEvents().

The application uses several threads and GetUserEvent() is used in several of the threads. All threads start up normally and signaling between the threads are working ok. The problem starts when the main thread post a message to all threads, asking them to terminate simultaneously. The failure occur randomly in one of the thread at GetUserEvent(). When we gradually reduced the number of threads, the frequence of the failure also decrease.

It looks like the functions is not multithread safe?

When testing the CVI2009 BETA, we didn't observe this phenomenon. The beta test machine is a slower machine (Intel Celeron 2.6gHz, XP Sp2). The development machine is a Intel Xeon 3.6Ghz with XP Sp3.

Hopefully this can be sorted out.

Jan

[nickb]

Hey Jan - 

At the time of the crash, can you tell what module is crashing?  The easiest way to do this is to wait until the crash happens, open the modules window (Window»Modules) and find which module contains the crash address.

 

Thanks!

NickB

National Instruments 

[Gaus]

Hi,

The general protection fault happens at this address:

 thread id 0x00000FEC:   The program has caused a 'General Protection' fault at 0x684604C8.

According to the module list, this should be cvirte.dll.

Jan

[nickb]

Thanks for the info - 

At this point, things become a little more difficult to diagnose, but if you can get me either of the following two things, it will get us started down the right road most quickly.  

• The quickest way to resolution of this issue would be if you could get me a small amount of source code I could run that would reproduce the issue.  You could place it behind out firewall on our ftp site.
• If you can't get me code, or code that I can run and reproduce the issue (requires hardware etc.), a crash dump would be the second best thing.  Check this out for instructions on generating a crash dump, and let me know if you have any questions.

Thanks

NickB

National Instruments 

[Gaus]

Hi,

¨

I'v created a full crash dump using DrWatson, but I'm not able to put in on your FTP site. I get access denied when I want to copy it to the incoming directory.

Jan

[nickb]

Hmm... That's not expected.  I'm able to copy to it from outside our firewall.  Is there any chance you could try from another computer?  If not, would you give me permission to get your email address from our forum administrator so that we can work something else out?

Thanks,

NickB

National Instruments 

[Gaus]

I moved outside our firewall and was able to transfer the file. The file name is pmuserdmp.zip.

[nickb]

Hey Jan - 

After a quick initial investigation, it looks like the root of this issue may indeed be a thread safety issue regarding the use of InstallWinMsgCallback, and RemoveWinMsgCallback.  From what I can tell from the dump, it looks like you may be using these functions from many different threads.  They are intended to be threadsafe, but it looks like the number of threads you have using them may have revealed a small hole in our synchronization.

However, this would not be a new problem, and it likely simply the result of a race condition.  You mentioned it didn't happen with the beta, but that the beta was running on another machine.  Would it be possible for you to take the officially released CVI run-time engine (c:\windows\system32\cvirte.dll) to the machine you have the beta installed on, and place the officially released RTE into the application's directory?  I'm assuming that even using the new RTE, the crash will not occur on that machine because of timing differences introduced by the different machine. 

thanks,

NickB

National Instruments 

[Gaus]

Hi,

I'm using InstallWinMsgCallback() for each thread and PostMessage() to control the threads. I did a little test and inserted Sleep(50) between each PostMessage() call to give the posted thread som time to proceed before next thread was posted. The problem disappeared so I'm sure you are on the right track.

I'll do a test as you requested tomorrow.

Jan

[Gaus]

Hi,

I've move the released cvirte.dll to the test machine and observed that the same failure occured.

Then I switched back to the beta cvirte.dll. After repeating the sequence several times, the same failure occured for this dll, but not so frequently.

Jan