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?
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?
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.
* 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
* 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