Release mode vs debug mode

Joined
4/5/08
Messages
267
Points
38
I tried to be over adventurous and tweaked my code a little bit. Now my project compiles in both release and debug mode while runs only in debug mode. It crashes in release mode.

Anybody ever faced a similar problem?:sos:
 
That probably means that you are writing to or deleting memory that has not been allocated. The same thing has happened to me before.
 
But then it should happen when I do it in both; debug and release; mode.

Here I face the problem only in release mode. I know both modes use different areas of heap to allocate memory, but that should not be a problem.

While I burn my midnight oil trying to find the bug, suggestions are welcome :D
 
I know what you are thinking. I thought the same thing.

Read this thread: https://www.quantnet.com/threads/resizing-a-vector-throws-a-bad_alloc.2393/

QUantnet is acting weird, so if that link doesn't work, then search for a thread titled "Resizing a Vector Throws a bad_alloc"

In that thread I state: "I'm also having some problems where my code will crash in release mode, but not in debug mode. I haven't investigated it yet though."

It was caused by a memory problem. I was writing past the range of an array that was buried deep in my code.
 
I figured out that my copy constructor is having problem.

I have two issues now:

1. Why does it work in debug mode and not in release mode?

2. It was working all fine till I changed my code. And then I rolled back and now it is not working

Here is my copy constructor; It does not go beyond "After getting rows and columns". It does not print value of "row"

Code:
//Copy Constructor
Matrix::Matrix(Matrix& matrix){

    cout<<"Copy Constructor\n";
    row = matrix.getRow();
    column = matrix.getColumn();
    
    cout<<"After getting rows and column\n";
    cout<<row<<endl;
    cout<<column<<endl;

    //Allocate Memory for rows
    element = new double*[row];

    cout<<"After allocating memory for rows\n";

    //Alocate Memory for Columns of each Row
    for(int iCount=0;iCount<row;iCount++)
        element[iCount] = new double[column];

    cout<<"After Allocating new memory\n";
    for(int rowCount=0;rowCount<row;rowCount++)
        for(int columnCount=0;columnCount<column;columnCount++)
            element[rowCount][columnCount] = matrix[rowCount][columnCount];

    cout<<"Before Returning\n";

}
I am calling it in main using Matrix Tmp_A = A.

I have also checked that A.getRow() returns the correct value.
 
i have heard of similar situations it seems you may have to release a configuration set and terminate legal operative binding the data or search recall in the fix is looping and not allowing sensitve co op feed to relay at least thats what their teaching us in theory try letting your pc run for a while and see if you can back test the terminal speed maybe that will de frost the bug link into an 1 ,2 drop mode eliminating your control charge to meet data requirements then try cleaning out your disk drive... and sit on it fora day or two if you still have the problem try extending your program selection and dis configure your server dataport to a new or slighty used operating system hope it helps
 
ihope it helps

Doubt it.

Aditya, I have had the same problem. The OS can be inconsistent as to how it handles that kind of error, it seems. I think if I wrote past the end of C-style arrays I would get one incarnation, and if I wrote past the end of C++ vectors I would get another.

Try going to the build menu and "cleaning" the project and solution and then "building" (not rebuilding). Sometimes the compiler doesn't recognize all the dependencies and it mixes old and new code.
 
My suggestion is to replace raw memory allocation with an stl vector and let it deal with memory issues. Just do it in a clever way instead of just push_back.
 
Try going to the build menu and "cleaning" the project and solution and then "building" (not rebuilding). Sometimes the compiler doesn't recognize all the dependencies and it mixes old and new code.

It sounded more reasonable, I tried it but it did not help.

Thanks anyways.
 
My suggestion is to replace raw memory allocation with an stl vector and let it deal with memory issues. Just do it in a clever way instead of just push_back.

Will surely do it after the finals are over. I would certainly not want my code not to work in debug mode too :D
 
It it tough to comment on particular scenario. But, it could happen because of difference in optimization levels. When optimization is not enabled, compiler keeps all the temporary variables you created for legibility. At higher optimization levels, these variables may get optimized out.
Debug mode usually uses optimization level -O0. Release can be any thing depending on the compiler and IDE. Take your release config and add -g option to it to do an apples-to-apples comparison.

If you changed any interface section of your classes, always do clean compile.
 
Back
Top Bottom