Release version of program crashes

[Double_D]

John,

It looks like the RUN button callback isn't reached in the release version.  I added some diagnostic fprintf messages to the callback, including one as the first executable statement in the function.  If I run the code in the debugger, it works fine, as usual, and the diagnostic message is printed to file.  If I run the release version, however, it crashes when the RUN button is pressed and no diagnostic message appears.  Is there any useful info in the crash data captured by Windows?

[John_M.]

Hi - there should be some useful information in the Windows Event Viewer that will help us determine what is going on. Right-click on My Computer, and select Manage. In the Computer Management window, expand Computer Management»System Tools»Event Viewer. If you are on Windows XP, select Application. If you are on Window Vista/7, select Windows Logs»Application. There should be an error listed here that corresponds to your application. If you cause the app to crash immediately before looking at the log, then your app should be the most recent error.

Please send us the text information that is logged here in the properties. Currently, you should be most interested in the "Faulting module name" and the "Fault offset". If the faulting module is your application, then some instruction in your application is causing the crash, however, is the faulting module is CVI, then something in CVI is related to the root cause of the crash.

John M

[Double_D]

John,

Here is the event viewer info from the crash:

Faulting application motorcontroller.exe, version 1.0.0.0,

faulting module cvirte.dll, version 8.5.1.356,

fault address 0x0024539c.

[John_M.]

Thanks! So, from this, we are able to tell that the crash is happening in cvirte.dll, the CVI Run Time Engine. I would like to encourage you to install the most recent version of the CVI Run Time Engine, 2009 SP1. There are two reasons for this... 1) there are bug fixes in the new version that could fix the issue, and 2) if the new version does not fix the problem, the new version has the ability to give us useful crash information which can help us debug the issue.

If the crash still occurs in the new version, please generate a crash dump and post it so that we can take a look and see where the crash is taking place. Here is an article on Generating Crash Dumps for Analysis by NI.

Thanks,

John M

[Double_D]

John,

I have generated the Dr. Watson debug files for the application.  The user.dmp file is over 12MB zipped, however, and the size limit for attachments is apparently 5MB.  Any suggestions as to how to get the file to you?

[John_M.]

You can FTP the zip file to us. On Monday, please upload the zip file to ftp://ftp.ni.com/incoming, and let us know the name of the zip file you posted.

Thanks, and have a great weekend!

John M

[Double_D]

I have posted the .log and .dmp files on the ftp site as SDPT_crash.zip.

[nickb]

I took a quick look at the crash dump, and it looks like a bad pointer (a non-null junk value) is being passed to SetCtrlVal for panel 1 and control 6. 

The value of the bad pointer is 0x203a3431.  Each byte in this pointer corresponds to an ASCII character that may be found in a string displayed to users, which leads me to speculate that you're overflowing a char buffer - likely a char buffer declared directly before the pointer you're using for control 6. 

This is a common culprit in crashes that happen in release mode but not debug mode.  In debug mode, the overflow is either caught by the debugger or the overflow is absorbed by (and corrupts...) the debuginfo surrounding each of your variables.  In release mode, there is no double checking of your boundaries, and there is no debug info to cushion an overflowing buffer.

NickB

National Instruments

[Double_D]

I looked at all of the SetCtrlVal calls in the program, trying to find a possible pointer problem.  In the code fragment below, I changed the declaration of c to a character array, as there was no malloc or similar allocation code for the memory pointed to by *c.  The program still crashes when I run the release executable, however.

int pnl_wiz_load ( int lock )
{

    //char * c;
    char c[80];
    int i;
    float f;
    
    prof_param_get ( p, PROF_NAME, &c);
    SetCtrlVal ( pnl_wiz, WIZ_PANEL_WIZ_PROF_NAME, c);
    
    prof_param_get ( p, USER_NAME, &c);
    SetCtrlVal ( pnl_wiz, WIZ_PANEL_WIZ_USER_NAME, c);
    
    ....

So it seems that there may indeed have been a pointer error, but it doesn't appear to be directly related to the crash.  I have posted the latest Dr. Watson files on the ftp site as SDPT_2.zip. 

[nickb]

A couple quick thoughts:

First, the code you commented out explains the first crash you reported.  You were passing the address of your char * variable (c) to the function prof_param_get.  My guess is that the third parameter of prof_param_get is a void *, and expects a valid buffer to be passed to it.  Because you passed the address of c to the function, the function wrote to that address as if it were a valid buffer - thus resulting in a pointer value that was actually a bunch of characters.

Next, there's not really any need to pass the address of statically sized array, as you're doing now.  &c and c are actually the same thing, but passing it as &c is unnecessary and confuses matters somewhat.  I'm guessing this code is now working as expected, because the prof_param_get function is getting the buffer it expects.

Finally - in the crash dump you've posted, the crash occurs as we are trying to return internally from one of our functions.  This nearly always indicates stack corruption - like a buffer has overflown.  Also - it crashes in the function CmtReadTSQData.  When this function is called, you request 19791432 items from the queue.  Is that a number of items you would expect to read from the queue? Could you post the bit of code that's calling CmtReadTSQData?  

It seems like many of these issues could be resolved by adding some logging to your code, printing pointer values, what they point at, checking that the values printed make sense, and double checking the implementation details (does the function allocate a buffer, or does it expect a valid buffer to be passed to it?) of some of the functions you're calling.

NickB

National Instruments