1. Guest,
    If you need help getting to know Xenforo, please see our guide here. If you have feedback or questions, please post those here.
    Dismiss Notice

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

Discussion in 'Archived Threads 2001-2004' started by Gordon Moore, Mar 14, 2003.

  1. Gordon Moore

    Gordon Moore Second Unit

    Joined:
    Nov 1, 2000
    Messages:
    340
    Likes Received:
    0
    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 [​IMG]

    It's MSVisualC++ version 6 with the latest service pack
     
  2. Gordon Moore

    Gordon Moore Second Unit

    Joined:
    Nov 1, 2000
    Messages:
    340
    Likes Received:
    0
  3. Max Leung

    Max Leung Producer

    Joined:
    Sep 6, 2000
    Messages:
    4,612
    Likes Received:
    0
    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.
     
  4. BrianB

    BrianB Producer

    Joined:
    Apr 29, 2000
    Messages:
    5,211
    Likes Received:
    1
    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!
     
  5. Gordon Moore

    Gordon Moore Second Unit

    Joined:
    Nov 1, 2000
    Messages:
    340
    Likes Received:
    0
    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 [​IMG]


    F*CK

    Okay, whew, now I feel better [​IMG]
     
  6. Steven K

    Steven K Supporting Actor

    Joined:
    Jan 10, 2000
    Messages:
    832
    Likes Received:
    0
    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. Gary King

    Gary King Second Unit

    Joined:
    Apr 13, 1999
    Messages:
    480
    Likes Received:
    0
    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:

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

Share This Page