Debug build works, release build crashes! 
Author Message
 Debug build works, release build crashes!

Hi all,

   I'm having problems with the development of a large project, trying
to get a release build to run.  The debug build runs fine, however a
release build will always crash, either at startup, or soon after,
depending on which optimisations I enable (see below).  The problem
occurs with all versions of VC from VC5 through to VC6 with SP3.  It's
an MFC app.

   I've narrowed it down to optimisations (the debug build also crashes
if I
enable optimisations, with everything else left the same), however my
attempts to narrow down the problem to any one section of the project
have been totally unsuccessful.  I have to disable optimisations in
basically the WHOLE project before it will run without crashing.  This
makes me suspect that it is a problem optimising the code from a
template library which
virtually all of the code uses.

   But I'm not really sure how to narrow it down any further than
that...  Does anyone have any ideas, or know of any optimisation bugs in
VC++ that may be applicable here?

Thanks for ANY help, I'm getting pretty desparate, as this program
really needs the optimisations to run at a decent speed!

Stephen French.



Fri, 28 Dec 2001 03:00:00 GMT  
 Debug build works, release build crashes!
Stephen:

While I wouldn't completely rule out the optimizations, I certainly wouldn't
look at them first for the fault.  It's much more likely that the
optimizations are making an inherent problem in the code more visible, such
as changing the padding in structures, and uncovering random pointers
thereby.  I suspect that you're right about it being a problem that is
diffused throughout your code, but I suspect that it's improper use of
<something>.

Have you tried running the optimized code under the de{*filter*}?  Does that
give you any hints as to where the problem might be?

Is this a new problem?  A "large project" should have been run as a release
version, so you might want to look at things that have been added/changed
recently.

Can you break the project apart into separate modules for testing?  The
smaller the amount of code in which to look for the problem, the quicker
you're likely to find it.

A very good option would be to try either Purify or Bounds Checker on your
code, they are both very good at finding problems in code.  Purify has a
trial version available for download, I don't know if BC does or not.

If none of these ideas helps, try providing more details about the problem,
OS, basic ideas of what the code does, code fragments if possible.

Luck!

--

-Steven M. Forrester
Directeur Dveloppement
Capsule Technologie


Quote:

> Hi all,

>    I'm having problems with the development of a large project, trying
> to get a release build to run.  The debug build runs fine, however a
> release build will always crash, either at startup, or soon after,
> depending on which optimisations I enable (see below).  The problem
> occurs with all versions of VC from VC5 through to VC6 with SP3.  It's
> an MFC app.

>    I've narrowed it down to optimisations (the debug build also crashes
> if I
> enable optimisations, with everything else left the same), however my
> attempts to narrow down the problem to any one section of the project
> have been totally unsuccessful.  I have to disable optimisations in
> basically the WHOLE project before it will run without crashing.  This
> makes me suspect that it is a problem optimising the code from a
> template library which
> virtually all of the code uses.

>    But I'm not really sure how to narrow it down any further than
> that...  Does anyone have any ideas, or know of any optimisation bugs in
> VC++ that may be applicable here?

> Thanks for ANY help, I'm getting pretty desparate, as this program
> really needs the optimisations to run at a decent speed!

> Stephen French.




Fri, 28 Dec 2001 03:00:00 GMT  
 Debug build works, release build crashes!
1) Just because the bug appears when optimization is turned on doesn't
mean you can blame it on "optimisation bugs in VC++." You could be
making assumptions (e.g. about order of evalutation) which happen to
be true for debug builds, but not optimized builds.

2) You can use #pragma optimize() to turn optimization off on a
function by function basis. Once you narrow it down to a specific
function, you can probably figure out what code is confusing the
optimizer and change it (and report the bug, if it is a VC bug).

On Mon, 12 Jul 1999 21:42:18 +1000, Stephen French

Quote:

>Hi all,

>   I'm having problems with the development of a large project, trying
>to get a release build to run.  The debug build runs fine, however a
>release build will always crash, either at startup, or soon after,
>depending on which optimisations I enable (see below).  The problem
>occurs with all versions of VC from VC5 through to VC6 with SP3.  It's
>an MFC app.

>   I've narrowed it down to optimisations (the debug build also crashes
>if I
>enable optimisations, with everything else left the same), however my
>attempts to narrow down the problem to any one section of the project
>have been totally unsuccessful.  I have to disable optimisations in
>basically the WHOLE project before it will run without crashing.  This
>makes me suspect that it is a problem optimising the code from a
>template library which
>virtually all of the code uses.

>   But I'm not really sure how to narrow it down any further than
>that...  Does anyone have any ideas, or know of any optimisation bugs in
>VC++ that may be applicable here?

>Thanks for ANY help, I'm getting pretty desparate, as this program
>really needs the optimisations to run at a decent speed!

>Stephen French.


Don Grasberger
(remove --- from address to e-mail)


Fri, 28 Dec 2001 03:00:00 GMT  
 Debug build works, release build crashes!
: 1) Just because the bug appears when optimization is turned on doesn't
: mean you can blame it on "optimisation bugs in VC++." You could be
: making assumptions (e.g. about order of evalutation) which happen to
: be true for debug builds, but not optimized builds.

: 2) You can use #pragma optimize() to turn optimization off on a
: function by function basis. Once you narrow it down to a specific
: function, you can probably figure out what code is confusing the
: optimizer and change it (and report the bug, if it is a VC bug).
<snip>

Knowledge Base article Q216181
<URL:http://support.microsoft.com/support/kb/articles/q216/1/81.asp>
details a bug in global optimisation in VC++ 5.0 and 6.0 that is easy
to run into.  It is fixed by VC++6.0SP3, but there is no fix for 5.0
yet.

--
Any opinions expressed are my own and not necessarily those of Laser-Scan.



Fri, 28 Dec 2001 03:00:00 GMT  
 Debug build works, release build crashes!
OTH, if he's passing structures by value, I might be able to recommend one
or two minor optimizations...  :-)

--

-Steven M. Forrester
Directeur Dveloppement
Capsule Technologie


Quote:

> : 1) Just because the bug appears when optimization is turned on doesn't
> : mean you can blame it on "optimisation bugs in VC++." You could be
> : making assumptions (e.g. about order of evalutation) which happen to
> : be true for debug builds, but not optimized builds.

> : 2) You can use #pragma optimize() to turn optimization off on a
> : function by function basis. Once you narrow it down to a specific
> : function, you can probably figure out what code is confusing the
> : optimizer and change it (and report the bug, if it is a VC bug).
> <snip>

> Knowledge Base article Q216181
> <URL:http://support.microsoft.com/support/kb/articles/q216/1/81.asp>
> details a bug in global optimisation in VC++ 5.0 and 6.0 that is easy
> to run into.  It is fixed by VC++6.0SP3, but there is no fix for 5.0
> yet.

> --
> Any opinions expressed are my own and not necessarily those of Laser-Scan.



Fri, 28 Dec 2001 03:00:00 GMT  
 Debug build works, release build crashes!
To pinpoint the crash, you might want to debug the release build, optimized
or not. There are many ways to do that, and here is just one combination of
compiler and linker arguments/switches.

To compile: cl /Z7 /MD /c
To link: link /debug /pdb:<your pdb> ...

To verify that you have a release build, check with the depends.exe utility
program, which is available in the platform SDK.

tr.

Hi all,

   I'm having problems with the development of a large project, trying
to get a release build to run.  The debug build runs fine, however a
release build will always crash, either at startup, or soon after,
depending on which optimisations I enable (see below).  The problem
occurs with all versions of VC from VC5 through to VC6 with SP3.  It's
an MFC app.

   I've narrowed it down to optimisations (the debug build also crashes
if I
enable optimisations, with everything else left the same), however my
attempts to narrow down the problem to any one section of the project
have been totally unsuccessful.  I have to disable optimisations in
basically the WHOLE project before it will run without crashing.  This
makes me suspect that it is a problem optimising the code from a
template library which
virtually all of the code uses.

   But I'm not really sure how to narrow it down any further than
that...  Does anyone have any ideas, or know of any optimisation bugs in
VC++ that may be applicable here?

Thanks for ANY help, I'm getting pretty desparate, as this program
really needs the optimisations to run at a decent speed!

Stephen French.



Fri, 28 Dec 2001 03:00:00 GMT  
 Debug build works, release build crashes!
See below.

Best of luck!
--

-Steven M. Forrester
Directeur Dveloppement
Capsule Technologie

Quote:

>    I tried building a debug build exactly as usual, with assertions,
> debug memory allocator, etc, etc, with only optimisations enabled, and
> when I ran it, I usually got weird assertions that had never fired
> before, about various pointers being null.

This is a major clue.  you should track those pointers back, see where they
are being initialized, having values assigned, etc. set breakpoints there,
and watch what's happening.

Quote:

>    It doesn't die immediately either, which means a *lot* of very
> intricate code has executed before it actually crashes.  That pretty
> much rules out the option of stepping through all the code up until the
> point where it crashes.

Not necessary.  Set breakpoints as I described above.  If they don't want to
work, do it in a regular (non-optimized) debug version, and watch things
there.  Pay particular attention to array overwrites.

Quote:
>    Unfortunately it has *never* run 100% correctly as a release build.
> I know, that's terrible, but there are reasons other than mere
> laziness.  Also, when I started working on this project, there was
> already lots of existing code, so in a sense, it's all "new".

Ah, the life of a programmer...

Quote:
> > A very good option would be to try either Purify or Bounds Checker on
your
> > code, they are both very good at finding problems in code.  Purify has a
> > trial version available for download, I don't know if BC does or not.

>    Thanks, I'll give them a look.  Are they much more sophisticated than
> the standard debug allocators provided with VC6 ?

Very much so.  You'll be amazed.


Sat, 29 Dec 2001 03:00:00 GMT  
 Debug build works, release build crashes!
See below.

--

-Steven M. Forrester
Directeur Dveloppement
Capsule Technologie

Quote:
> > making assumptions (e.g. about order of evalutation) which happen to
> > be true for debug builds, but not optimized builds.

>    I think there's a good chance of that.  But how do I find out where
> it happens?

Anyplace your code is doing things like

if(function1() && function2())
or
while( x || function3())

if function3 modifies x, you're toast.

You can NEVER count on the order of evaluation of parameters passed to
things like if, for, while, etc.  It's *probably, usually* consistent, but
certainly not always.



Sat, 29 Dec 2001 03:00:00 GMT  
 Debug build works, release build crashes!

...

Quote:
> Anyplace your code is doing things like

> if(function1() && function2())
> or
> while( x || function3())

> if function3 modifies x, you're toast.

> You can NEVER count on the order of evaluation of parameters passed to
> things like if, for, while, etc.  It's *probably, usually* consistent, but
> certainly not always.

That is not true.

The C and C++ language specifications guarantee
that expressions involving && or || with operands of
built-in types will be evaluated in a certain order
with respect to those operands.  This has nothing
to do with whether the result is used in a control
statement.  So, for example, if function1() returns
an int and function2() returns an int, function1()
must be evaluated first and function2() must not be
evaluated unless function1() returned non-zero.
This language feature is often called "short circuit
evaluation" and is very useful.  It allows code such
as the following to be well-defined:
    bool Try(bool * pFlag)
    {
        return (0 != pFlag && * pFlag);
    }

--
Larry Brasfield
Above opinions may be mine alone.



Sat, 29 Dec 2001 03:00:00 GMT  
 Debug build works, release build crashes!

Quote:

>Anyplace your code is doing things like

>if(function1() && function2())
>or
>while( x || function3())

>if function3 modifies x, you're toast.

Why? The built-in operators && and || evaluate their operands left to right,
and there is a sequence point at each && or ||. You can think of it like
this. The sub-expressions in:

 a && b && c

are evaluated as, subject to the short-circuiting described below:

 bool _a = a;
 bool _b = b;
 bool _c = c;

Short-circuiting means that evaluation stops as soon as the truth of the
overall expression can be determined, so that if _a is false, _b and _c
won't be evaluated.

So, it is well-defined for function3() to modify x, and the following
silliness is also well-defined:

 if (x && --x) ...

Contrast this to something like:

 if (x & --x) // Or +, *, %, etc.

This is undefined, because there's no sequence point at other binary
operators, and the order of evaluation is unspecified anyway.

Quote:
>You can NEVER count on the order of evaluation of parameters passed to
>things like if, for, while, etc.  It's *probably, usually* consistent, but
>certainly not always.

That's not really true. The condition part of an if or while statement is a
single expression or declaration. for-statements have three parts, and the
order of evaluation there is well-defined. You're thinking of operands and
function arguments, but you can count on the order of evaluation of the
operands of the built-in && and ||, and you can count on the sequence point
at each operator && and ||. However, overloaded versions lose these nice
properties, and you get function call semantics. That's one reason you never
see these operators overloaded. The main reason is that there's no point in
overloading them. Other operators that have well-defined evaluation order
and sequence points include ?: and the comma operator.

--
Doug Harrison

Visual C++ MVP



Sat, 29 Dec 2001 03:00:00 GMT  
 Debug build works, release build crashes!

Thanks for your detailed reply!

Quote:

> Stephen:
> While I wouldn't completely rule out the optimizations, I certainly wouldn't
> look at them first for the fault.  It's much more likely that the
> optimizations are making an inherent problem in the code more visible, such
> as changing the padding in structures, and uncovering random pointers
> thereby.  I suspect that you're right about it being a problem that is
> diffused throughout your code, but I suspect that it's improper use of
> <something>.

> Have you tried running the optimized code under the de{*filter*}?  Does that
> give you any hints as to where the problem might be?

   I tried building a debug build exactly as usual, with assertions,
debug memory allocator, etc, etc, with only optimisations enabled, and
when I ran it, I usually got weird assertions that had never fired
before, about various pointers being null.  Of course, it was next to
impossible to determine for sure the state of the program at the time
because of variables being optimised out, registers reused for other
purposes and all that stuff.  This also made it extremely difficult to
step through code in any sensible way, set breakpoints accurately, etc.

   It doesn't die immediately either, which means a *lot* of very
intricate code has executed before it actually crashes.  That pretty
much rules out the option of stepping through all the code up until the
point where it crashes.  It's a game, and there's a LOT of complicated
decision making going on all the time, that may potentially be stuffing
something up.

Quote:
> Is this a new problem?  A "large project" should have been run as a release
> version, so you might want to look at things that have been added/changed
> recently.

   Unfortunately it has *never* run 100% correctly as a release build.
I know, that's terrible, but there are reasons other than mere
laziness.  Also, when I started working on this project, there was
already lots of existing code, so in a sense, it's all "new".

Quote:
> Can you break the project apart into separate modules for testing?  The
> smaller the amount of code in which to look for the problem, the quicker
> you're likely to find it.

   It's tricky.  It is very difficult to give any part of the code the
workout it would need for the wide variety of possible inputs.  I could
easily spend weeks just writing the simplest of test harnesses for it,
and keeping such a thing maintained would be a bigger job than writing
the code itself would have been.  A real nightmare for our (very small)
team.

Quote:
> A very good option would be to try either Purify or Bounds Checker on your
> code, they are both very good at finding problems in code.  Purify has a
> trial version available for download, I don't know if BC does or not.

   Thanks, I'll give them a look.  Are they much more sophisticated than
the standard debug allocators provided with VC6 ?

Quote:
> If none of these ideas helps, try providing more details about the problem,
> OS, basic ideas of what the code does, code fragments if possible.

   It's hard to do that without being able to work out what approximate
part of the code is failing.  I'm just trying to find out that much, and
it's proving very difficult.

Stephen.



Sun, 30 Dec 2001 03:00:00 GMT  
 Debug build works, release build crashes!

Quote:

> 1) Just because the bug appears when optimization is turned on doesn't
> mean you can blame it on "optimisation bugs in VC++." You could be

   I didn't!  I'm just including it as a likely candidate, because I've
encountered so many other bugs in the compiler, and I guess I'm losing
faith!  :-)

Quote:
> making assumptions (e.g. about order of evalutation) which happen to
> be true for debug builds, but not optimized builds.

   I think there's a good chance of that.  But how do I find out where
it happens?

Quote:
> 2) You can use #pragma optimize() to turn optimization off on a
> function by function basis. Once you narrow it down to a specific
> function, you can probably figure out what code is confusing the
> optimizer and change it (and report the bug, if it is a VC bug).

   I know about this one, and it would be great, except...  I don't
think I can turn off optimisations for a template.  Here's my test
program:

#pragma optimize("", off)

template <class TYPE>
struct Fooey
{
  static TYPE Seven( TYPE inValue )
  {
    return inValue * 7;
  }

Quote:
};

// Try to force instantiation of the template here to make it
not-optimise it:
// (but it doesn't work)
template struct Fooey<int>;

int OptimisedFunction( int x )
{
  return Fooey<int>::Seven( x );

Quote:
}

#pragma optimize("", on)

   Now when I whack this in a .cpp file and compile with optimisations
on, the #pragma makes no difference.  It still generates an optimised
version of Fooey<int>::Seven().  Now this doesn't surprise me (in fact,
I actually expected it would do that before I tried it).  However, it
means the only way I can disable optimisations is by disabling them in
the entire compilation unit.  Which means I can't disable them just for
my template-class library, and enable them for everything else.  Bummer!

Stephen.



Sun, 30 Dec 2001 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. Debug Build works Release build doesn't?

2. Debug build works correctly but release build doesnt (sometimes)

3. VC6 Debug Build Works Fine - but Release Build Gives Error

4. Q: Dialog Tooltips work in DEBUG build but not under RELEASE Build

5. Debug build works correctly but release build doesnt (sometimes)

6. debug works fine but release build crashes.

7. Debug build fine, release crashes unless we link with debug Multi-Threaded library

8. Debug build breaks, Release build ok

9. Debug Build vs. Release Build

10. Protection Violation in Release Build but not in Debug Build

11. Error in Release build but not Debug build

12. Message Handler on Release build and debug build

 

 
Powered by phpBB® Forum Software