Jump to content

Sign up for a free account to remove the pop-up ads

Signing up for an account is fast and free. As a member you can join in the conversation, enter contests and remove the pop-up ads that guests get. Click here to create your free account.


Hey MS Visual C/C++ Gurus...HELP!

  • You cannot start a new topic
  • Please log in to reply
6 replies to this topic

#1 of 7 OFFLINE   Gordon Moore

Gordon Moore

    Second Unit

  • 340 posts
  • Join Date: Nov 01 2000

Posted March 14 2003 - 07:38 AM

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 Posted Image

It's MSVisualC++ version 6 with the latest service pack
In Violet Light
The Tragically Hip

#2 of 7 OFFLINE   Gordon Moore

Gordon Moore

    Second Unit

  • 340 posts
  • Join Date: Nov 01 2000

Posted March 14 2003 - 08:09 AM

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.microsof.....ver write.asp
In Violet Light
The Tragically Hip

#3 of 7 OFFLINE   Max Leung

Max Leung


  • 4,612 posts
  • Join Date: Sep 06 2000

Posted March 14 2003 - 08:15 AM

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.
Mahatma Gandhi, as you know, walked barefoot most of the time, which produced an impressive set of calluses on his feet. He also ate very little, which made him rather frail and with his odd diet, he suffered from bad breath. This made him...a super-callused fragile mystic hexed by halitosis.


#4 of 7 OFFLINE   BrianB



  • 5,211 posts
  • Join Date: Apr 29 2000

Posted March 14 2003 - 08:46 AM

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!
high resolution ipod featuring dlp hd programming is the best, almost as good as playstation 2 with wega windows media on a super cd! ps2 and tivo do dolby tv with broadband hdtv!

#5 of 7 OFFLINE   Gordon Moore

Gordon Moore

    Second Unit

  • 340 posts
  • Join Date: Nov 01 2000

Posted March 14 2003 - 09:19 AM

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 Posted Image


Okay, whew, now I feel better Posted Image
In Violet Light
The Tragically Hip

#6 of 7 OFFLINE   Steven K

Steven K

    Supporting Actor

  • 832 posts
  • Join Date: Jan 10 2000

Posted March 15 2003 - 06:09 AM

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.

#7 of 7 OFFLINE   Gary King

Gary King

    Second Unit

  • 480 posts
  • Join Date: Apr 13 1999

Posted March 15 2003 - 07:09 AM

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:

 #define SAFE_DELETE(p) 
 if (p != NULL) { 
 delete p; 
 p = NULL; 
 #define SAFE_DELETE_ARRAY(p) 
 if (p != NULL) { 
 delete [] p; 
 p = NULL; 

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users