Program work fine when debugging but crashes when running normal

[bjb414]

The program work fine when debugging but it crashes when i try to run the .exe,

This is the function where it found the program crashes:

//if this size_population is big the program will crash
const int size_population = 900;

typedef std::vector< std::vector<float> > matrix;
  
 vector<float> temp_x,temp_f;

    matrix x,  factor;
    matrix x_p,  factor_p;



void alg_evo::mut_rep(){


 float   ran_m = 0.2 * normsinv(unifRand());

    x_p.clear();
    factor_p.clear();


            temp_x.clear();
            temp_f.clear();


        float x_mu,fac_mu;

 for(int j=0;j<size_population;j++){ 

            for(int i=0;i<size;i++){ 

                ran_m =  normsinv(unifRand());

                x_mu =(float)(x[i][j] +  normsinv(unifRand())* factor[i][j]);

                fac_mu = (float)(factor[i][j] * (1 + ran_m ));


                  temp_f.push_back(x_mu);
                  temp_x.push_back(fac_mu);

            }

            x_p.push_back(temp_x);
            factor_p.push_back(temp_f);

            temp_x.clear();
            temp_f.clear();

        }
//here the program fails

    }

what i'm doing wrong? why this happens?

[o3hC5Di1]

Hi there,

Could you be a little bit more specific about which error you are getting?
Is it possible that in your j/i for-loop x[i][j] goes out of memory-bounds because j is allowed to run high if size_population is high?

All the best,
NwN

[keskiverto]

Line 29 iterates over size_population elements.
Line 31 iterates over size elements.
The code present does not show that the x and factor each contain size vectors of size_population floats.
(Note: column-major access to row-major matrix is inefficient. Is that intentional and necessary?)


What does "fine debugging but crash running" mean? Do they refer to VS "debug" and "release" versions?

[bjb414]

Yes i meant the release version crashes but the debug version works fine, though i don't have any longer this problem,i not sure what i changed.

[andywestken]

i not sure what i changed.

Do you keep your code under version control? Or even just back it up regularly?

The memory layout of the debug and release versions will be different, so bugs related to memory trampling can turn up in one rather than the other (usually release.)

And, at least if you're using Visual C++, then variables you do not initialize will be filled with a pattern, including memory new-ed by the debug CRT (to make it easier to see where things are when you dump memory in a debugger.) But in the release build they will be filled with random values (whatever happens to be in that memory location.) So uninitialized variables will cause more problems in the release build.

Note that if it's some sort of memory damage issue, the errant code could be outside the function which is crashing. If you can reproduce the crash with a small app using just the code you posted, plus enough of your other code to get it to run, then you have a better chance of spotting whether or not the flaw is in this code.

Andy

PS From http://en.wikipedia.org/wiki/Magic_number_(programming) via http://stackoverflow.com/questions/127386/in-visual-studio-c-what-are-the-memory-allocation-representations

* 0xABABABAB : Used by Microsoft's HeapAlloc() to mark "no man's land" guard
               bytes after allocated heap memory
* 0xABADCAFE : A startup to this value to initialize all free memory to catch
               errant pointers
* 0xBAADF00D : Used by Microsoft's LocalAlloc(LMEM_FIXED) to mark uninitialised
               allocated heap memory
* 0xBADCAB1E : Error Code returned to the Microsoft eVC debugger when connection
               is severed to the debugger
* 0xBEEFCACE : Used by Microsoft .NET as a magic number in resource files
* 0xCCCCCCCC : Used by Microsoft's C++ debugging runtime library to mark
               uninitialised stack memory
* 0xCDCDCDCD : Used by Microsoft's C++ debugging runtime library to mark
               uninitialised heap memory
* 0xDEADDEAD : A Microsoft Windows STOP Error code used when the user manually
               initiates the crash.
* 0xFDFDFDFD : Used by Microsoft's C++ debugging heap to mark "no man's land"
               guard bytes before and after allocated heap memory
* 0xFEEEFEEE : Used by Microsoft's HeapFree() to mark freed heap memory