Hey MS Visual C/C++ Gurus...HELP! (1 Viewer)

Got the old "it works fine in debug but blows up in release problem"

Have a linked-list that looks good in debug mode but in the release compile of the dll the list picks up garbage. I'm not sure exactly where in the code it happens. I have an idea of the general area but it must be something else that tacks garbage onto the NextList pointer. Usually a termination or a boundary problem is what is was in the past but this time it's not so obvious.

Anyone know a way to make Debug mode function more like Release?

This sucks :frowning:

It's MSVisualC++ version 6 with the latest service pack

Found my own answer....IN The Release Project SettingsLink tab

Click Generate Debug Info...


There are a few other things to do.

Read here is anyone is interested:

http://msdn.microsoft.com/library/de...ver write.asp

I always encounter the same problem. Works great in Debug, but the Release would crash!

You will have to resort to the printf method of debugging, except in Windows you would use the MessageBox or AfxMessageBox functions.

So, in important sections of the suspect code, you can do something like:

CString debugString;
...
debugString.Format("Variable a = %d", a);
MessageBox(debugString);
...
suspected bad code
...
debugString.Format("Code made it here!");
MessageBox(debugString);

etc.

You may have to use AfxMessageBox instead, if the code section does not have a parent window handle.

Another alternative is to add a multiline CEdit control, and output your messages that way:

debugEditControlString += "logging message here";
UpdateData(FALSE);

or:

debugLog += "Your debug message here";
debugEditControl.SetWindowText(debugLog);

The likely reason for your crash is a boundary value problem. An index into an array has probably gone past the limit. In Debug mode no exception would occur because of all the extra padding in the heap that would hide any memory faults. In Release mode, the heap would be much smaller, and easy to step out of bounds with, causing an exception to happen much sooner or immediately.

Y'know, I really should install Boundschecker (commercial product)...dammit I keep forgetting about that handy tool. It is supposed to warn you about those things at compile-time.

The nasty memory bugs are the ones where just by putting in a printf, you adjust memory enough so that it goes away :-( Those can be hellish & I've seen them take days to find :-(

Anyway, I'd make judicious use of asserts & printfs dotted around the list handling functions/class.

It's useful to add a "enter/exit" message to your commonly called functions just to get a good idea of where things are dieing.

I'm sure you know all this though!

It's not a windows function...fortunately/unfortunately depending on your take on the whole thing.


It's an Oracle function and we use the dll as our "calculator" for our pension engine with user_exit calls to enter the dll...nothing overly special but works well.

shameless corporate promo: www.jea.ca


Wasted a good couple of hours on this....I was watching addresses throughout the program written to a little text file. Turns out it was a stupid missed initialization that was blowing up the works.

*pList = NULL;

Fixed everything


F*CK

Okay, whew, now I feel better

Yup... in debug mode, pointers automatically get assigned to a specific address (something like 0xcdcdcdcd); however in release mode, the pointer will point to a random location.

I always initialize my pointers to NULL (either in the class constructor or beginning of a function)... my professors beat this into me in college. I also check for NULL before deallocating memory which I allocated. Take the following code:

char * pMem;
pMem = NULL;
pMem = (char *)malloc(100);

if(pMem != NULL)
{
free(pMem);
pMem = NULL;
}

I've seen alot of code that is out there where the user will just call free() but I like to be careful.

Not just pointers.

In Debug mode, *all* memory is striped initially. In release mode, the memory is zeroed.

Microsoft uses a macro to handle deallocation: