compiling with o2 flag makes program to trow access violation_问答_开发者

I know it may be some once in life time question but I've stuck with it and i cann't think of any possible problem that's cousing this, I've written a code in c++ (somthing around 500 lines in seperate classes and files) using visual studio and while I compile it without optimization flag (/od) it works fine, but when I try to compile it using release configuration (/o2 flag for optimization) the program gives access violat开发者_高级运维ion and crashes. after some debuging i found out there is a this value is changing inside one of member functions but i can't see any direct use of pointer in the call stack were the pointer changes, can any one give any suggestion what makes that happen in only when optimization is enabled?

don't know if this may help you or not, but when I'm compiling using optimization I can see there is an assembly instuction added at the end of my first function call pop ebp don't know what this one does but what ever it is, this is where this pointer changes.

something new that i found while trying to debug using disassembler, there is 13 push instructions and only 10 pop instructions in the function that is causing the problem (the problem is caused by the last pop just before ret instruction) is it okay or not? (i'm counting all push,pop instructions in the functions that are called too.)

The reason you're seeing different behavior with and without optimizations is that your code (unintentionally) relies on undefined behavior. It just so happens to work if the compiler lays out data in one way, and breaks if the compiler lays it out differently.

In other words, you have a bug.

It may be in your already tested code, or it may be in how you use that code. In any case, as @Nim said in the comments, check wherever you allocate and free memory. Check that your classes follow the rule of three. Verify that you don't have a buffer overrun somewhere. And perhaps, try compiling it with different compilers as well. Use static analysis tools (MSVC has /analyze, Clang has --analyze. On Linux Valgrind may be a good bet).

But don't assume that it is a compiler bug. Those do occur, sure, but they're not commonly the source of such errors. In nearly every case, it is a latent bug in the developers own code. Just because it doesn't trigger every time, with every compiler flag doesn't mean it doesn't exist, or that it's the compiler's fault.

Since you say that a this pointer suddenly changes value leads me to believe that this is related to a heap corruption. On the other hand since you say this is related to optimized code or not, it might as well be related to the stack. One of the things the optimizer does, is that it removes unused variables put on the stack, that are never accessed.

This in fact means that when you are not compiling in optimized mode, there will be more variables present on the stack, thus making the memory layout somewhat different and in a sense add more memory space to the stack, which might have huge impact to how the software reacts to for example stack overflow.

If there are local variables that are never used, the program doesn't care if you corrupt the memory of the never used local variables. It's only when you corrupt memory that you actually use, when it becomes a problem.

There are different warning levels (four if I'm not mistaken) that you can tell the compiler to use. If you use the highest one a warning will be treated as a compiler error, which will halt the compilation process. This way you can notice local variables that will be removed when the code is optimized and can move you closer to the real problem. Start searching around these areas of the code to start with.

I also suggest that you cut away code and test, just to rule out where the problematic code is located, and gradually dig down close the problem. When you have no information you must start from the beginning (the main loop of the program) and try to isolate and rule out portions of the code that is working ok. "If I comment out this function call, then it doesn't crashes" might give you a hint :)