Home > Archive > VC STL > January 2006 > Are compiler optimizations unstable?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Are compiler optimizations unstable?
|
|
| Andrew Chalk 2006-01-09, 11:10 pm |
| I have a program that runs fine in its debug build. When I generate the
release build it crashed. I set breakpoints in the debugger and found
sections of code where the ADDRESS of std::string member variables would
change! Even though those variables were not being referenced.
What's going on here? Are the compiler optimizations in VC++ 2003 known to
be unstable? Is there one particular optimization that could be doing this?
As this was a first time for the release build with this project I turned up
a lot of the options on the Compiler Optimization and Code Generation tab.
E.g. Omit frame pointers, inline function exp., Pentium 4 optimization,
enable enhanced instruction set SSE2, pool strings, function level linking.
Many thanks.
| |
| Stephen Howe 2006-01-09, 11:10 pm |
| > I have a program that runs fine in its debug build. When I generate the
> release build it crashed.
You could be doing something illegal like overwriting the stack memory of
local variables but it works out that the debug build lets you "get away
with it". What is overwritten may not matter.
But for a release build with optimisation, it may matter a great deal.
I have seen plenty of instances of this.
I would look locally very carefully.
Using any arrays? No chance of writing off the beginning/end of them?
Stephen Howe
| |
| Carl Daniel [VC++ MVP] 2006-01-09, 11:10 pm |
| Andrew Chalk wrote:
> I have a program that runs fine in its debug build. When I generate
> the release build it crashed. I set breakpoints in the debugger and
> found sections of code where the ADDRESS of std::string member
> variables would change! Even though those variables were not being
> referenced.
> What's going on here? Are the compiler optimizations in VC++ 2003
> known to be unstable? Is there one particular optimization that could
> be doing this?
> As this was a first time for the release build with this project I
> turned up a lot of the options on the Compiler Optimization and Code
> Generation tab. E.g. Omit frame pointers, inline function exp.,
> Pentium 4 optimization, enable enhanced instruction set SSE2, pool
> strings, function level linking.
Your crash could be caused by an optimization gone awry, but it's much more
likely that it's undefined behavior that just happens to "work" in your
debug builds. Check carefully for use of undefined variables, over-indexing
of local variables, and so on.
As to the addresses of variables changing - the debugger is sometimes
 by optimized code, so don't put too much weight on things you see
there beyond low-level memory access and assembly-level instruction
stepping/execution. I'd be very suspicious of the omit frame pointer
optimization producing code that drives the debugger crazy.
-cd
| |
| Stephen Howe 2006-01-09, 11:10 pm |
| > I have a program that runs fine in its debug build. When I generate the
> release build it crashed. I set breakpoints in the debugger and found
> sections of code where the ADDRESS of std::string member variables would
> change! Even though those variables were not being referenced.
Further comments:
I once saw a "worked example" where a compiler vendor showed how a bug could
be masked in a debug build but was visible in the release build. They showed
the assembler generated and it become obvious as to why the debug build
"worked" and the release did not. This is quite a common problem.
I reckon the odds are 99.9% you have done something wrong.
About 0.1% chance you have found a compiler optimisation flaw.
I have found VC++ 2003 very stable and know of very few bugs where it
deviates from the standard.
I have not had one problem with code generation, just a problem with its
understanding of C++.
Unless you know that you write nearly flawless C++ code, the odds favour the
former.
Get a colleague to stare at the code. It might be obvious. It might be
subtle.
And remember the execution point which "causes" the bug can be quite far
from where the bug become "visible". That can be quite depressing but it is
true.
We all have blind spots, occasionally.
Cheers
Stephen Howe
| |
|
| Andrew Chalk wrote:
> I have a program that runs fine in its debug build. When I generate the
> release build it crashed. I set breakpoints in the debugger and found
> sections of code where the ADDRESS of std::string member variables would
> change! Even though those variables were not being referenced.
>
> What's going on here? Are the compiler optimizations in VC++ 2003 known to
> be unstable? Is there one particular optimization that could be doing this?
>
> As this was a first time for the release build with this project I turned up
> a lot of the options on the Compiler Optimization and Code Generation tab.
> E.g. Omit frame pointers, inline function exp., Pentium 4 optimization,
> enable enhanced instruction set SSE2, pool strings, function level linking.
I doubt it's compiler optimization. Look at variable initilazition.
Sometimes the compiler will do "nice" things for you in debug mode like
initialize your variables - numeric datatypes set to zero, etc. The
release config won't. This can lead to differences in behavior between
debug and release.
//Walt
| |
| Doug Harrison [MVP] 2006-01-09, 11:10 pm |
| On Fri, 06 Jan 2006 14:36:14 -0500, Walt <walt_askier@SHOESyahoo.com>
wrote:
>I doubt it's compiler optimization. Look at variable initilazition.
>Sometimes the compiler will do "nice" things for you in debug mode like
>initialize your variables - numeric datatypes set to zero, etc. The
>release config won't. This can lead to differences in behavior between
>debug and release.
The compiler does not actively set variables to zero in debug mode that
aren't supposed to be zero-initialized. What it can do is set variables to
certain non-zero values:
/RTC (Run-Time Error Checks)
http://msdn2.microsoft.com/en-us/library/8wtf2dfz.aspx
The CRT can also help:
Memory Management and the Debug Heap
http://msdn2.microsoft.com/en-us/library/bebs9zyz.aspx
--
Doug Harrison
Visual C++ MVP
| |
| Serge Skorokhodov (216716244) 2006-01-09, 11:10 pm |
| Andrew Chalk wrote:
> I have a program that runs fine in its debug build. When I
> generate the release build it crashed. I set breakpoints in
> the debugger and found sections of code where the ADDRESS of
> std::string member variables would change! Even though those
> variables were not being referenced.
>
<skip>
I encountered some similar problems when I ran into;) undefined
behaviour with complex initializers of static constants within
class bodies. The compiler definitely calculated addresses of
data members wrong spoiling variables all around as a result:( As
soon as I realized that it's me who's wrong, everything worked
correctly:)
--
Serge
| |
| Ben Voigt 2006-01-17, 7:09 pm |
|
"Andrew Chalk" <achalk@magnacartasoftware.com> wrote in message
news:ujGHUktEGHA.1676@TK2MSFTNGP09.phx.gbl...
>I have a program that runs fine in its debug build. When I generate the
>release build it crashed. I set breakpoints in the debugger and found
>sections of code where the ADDRESS of std::string member variables would
In optimized build, typically the "this" pointer is stored in a register.
When you add "this->m_strWhatever" to the watch window, the debugger finds
out that this is stored in a register and internally substitutes it. When
that register is later used as a temporary during a calculation, all your
member variables go wild, until the this pointer is restored.
You'll also see local variables with non-overlapping sharing the same
register or memory space, so if you watch them, assigning one will change
random other variables. But the variables have the right value when needed.
> change! Even though those variables were not being referenced.
>
> What's going on here? Are the compiler optimizations in VC++ 2003 known to
> be unstable? Is there one particular optimization that could be doing
> this?
>
> As this was a first time for the release build with this project I turned
> up a lot of the options on the Compiler Optimization and Code Generation
> tab. E.g. Omit frame pointers, inline function exp., Pentium 4
> optimization, enable enhanced instruction set SSE2, pool strings, function
> level linking.
>
> Many thanks.
>
| |
| Andrew Chalk 2006-01-18, 7:08 pm |
| Thanks to you and everyone else who replied. What you describe is consistent
with what I see. However, there is some kind of bug involving a std::string
being overwritten. This may be in my code, although it is puzzling that it
only occurs with a lot of optimizations on. I have substituted a C string
for the time being for that variable and the problem no longer occurs. I am
going to investigate further.
Once again, I appreciate your advice.
- Andrew
"Ben Voigt" <bvoigt@nospam.nospam> wrote in message
news:urGDfp3GGHA.1132@TK2MSFTNGP10.phx.gbl...
>
> "Andrew Chalk" <achalk@magnacartasoftware.com> wrote in message
> news:ujGHUktEGHA.1676@TK2MSFTNGP09.phx.gbl...
>
> In optimized build, typically the "this" pointer is stored in a register.
> When you add "this->m_strWhatever" to the watch window, the debugger finds
> out that this is stored in a register and internally substitutes it. When
> that register is later used as a temporary during a calculation, all your
> member variables go wild, until the this pointer is restored.
>
> You'll also see local variables with non-overlapping sharing the same
> register or memory space, so if you watch them, assigning one will change
> random other variables. But the variables have the right value when
> needed.
>
>
>
| |
| Ismo Salonen 2006-01-19, 8:04 am |
| -snip-
Which version of Visual Studio ? VC++6.0 std::string is not thread safe,
usually works in debug builds but in release mode it crashes.
VS2003 fixes this, propably also Vs2002.
I think there is a fix for this (VC++6.0) on dinkumware website.
ismo
| |
| Andrew Chalk 2006-01-23, 9:57 pm |
| This is VS 2003 (v7.1).
- A
"Ismo Salonen" <Ismo.Salonen@codeit.fi> wrote in message
news:%2366$M7PHGHA.1180@TK2MSFTNGP09.phx.gbl...
> -snip-
>
> Which version of Visual Studio ? VC++6.0 std::string is not thread safe,
> usually works in debug builds but in release mode it crashes.
> VS2003 fixes this, propably also Vs2002.
>
> I think there is a fix for this (VC++6.0) on dinkumware website.
>
> ismo
>
| |
| Ismo Salonen 2006-01-24, 4:00 am |
|
Finding this kind of bug tends to be hard. I've used GlowCode for this.
Trial period is free and the product itself is great. Finds out all
kinds of bugs, leaks also.
ismo
| |
| Andrew Chalk 2006-01-24, 7:07 pm |
| Thanks!
"Ismo Salonen" <Ismo.Salonen@codeit.fi> wrote in message
news:OJkiJjMIGHA.3984@TK2MSFTNGP14.phx.gbl...
>
> Finding this kind of bug tends to be hard. I've used GlowCode for this.
> Trial period is free and the product itself is great. Finds out all kinds
> of bugs, leaks also.
>
> ismo
>
|
|
|
|
|