Debug OK, Release NOT! 
Author Message
 Debug OK, Release NOT!

The project is a DLL.

The test program that uses this dll works fine in Debug version (which
includes the debug version of the DLL) but in the release version (which
uses the Release DLL) stops because "...memory could not be written".

If I build the release version of the DLL with the MDd option (instead of
MD), then the release version of the test program (which still uses the
Release version of the dll) halts for a Debug Assertion Failure in
dbgheap.c.

If I run the release version of the program with the debug version of the
DLL all works fine.

It's really a code problem or a wrong project setting ?

Thanks in adavnce



Sat, 25 May 2002 03:00:00 GMT  
 Debug OK, Release NOT!
There are several possibilities that can cause this problem
- struct alignment, sometimes there are differences in alignment in release
and debug (is the dll built with the same alignment)
- calling convention
- difference in debug and release dll (you already mentioned that there is!,
so the problem must be one of the other two)



Quote:
> The project is a DLL.

> The test program that uses this dll works fine in Debug version (which
> includes the debug version of the DLL) but in the release version (which
> uses the Release DLL) stops because "...memory could not be written".

> If I build the release version of the DLL with the MDd option (instead of
> MD), then the release version of the test program (which still uses the
> Release version of the dll) halts for a Debug Assertion Failure in
> dbgheap.c.

> If I run the release version of the program with the debug version of the
> DLL all works fine.

> It's really a code problem or a wrong project setting ?

> Thanks in adavnce



Sat, 25 May 2002 03:00:00 GMT  
 Debug OK, Release NOT!
When you use MDd you are just hiding the problem. You are probably
corrupting memory in some way - reading/writing beyond the end of
an array, using memory after freeing it, or something like that.

Enable debug information for your release build and use your de{*filter*}.

Quote:

> The project is a DLL.

> The test program that uses this dll works fine in Debug version (which
> includes the debug version of the DLL) but in the release version (which
> uses the Release DLL) stops because "...memory could not be written".

> If I build the release version of the DLL with the MDd option (instead of
> MD), then the release version of the test program (which still uses the
> Release version of the dll) halts for a Debug Assertion Failure in
> dbgheap.c.

> If I run the release version of the program with the debug version of the
> DLL all works fine.

> It's really a code problem or a wrong project setting ?

> Thanks in adavnce

--
.Bruce Dawson, Cavedog Entertainment.
Makers of Total Annihilation - http://www.*-*-*.com/


Sat, 25 May 2002 03:00:00 GMT  
 Debug OK, Release NOT!
It is possible that you allocate memory in one heap and de-allocate memory
in another heap. The release version of build and the debug version use
defferent heaps, that is the reason why the program crashes. Try only
allocate/de-allocate memory in one module.

Good luck.

Quote:
> The project is a DLL.

> The test program that uses this dll works fine in Debug version (which
> includes the debug version of the DLL) but in the release version (which
> uses the Release DLL) stops because "...memory could not be written".

> If I build the release version of the DLL with the MDd option (instead of
> MD), then the release version of the test program (which still uses the
> Release version of the dll) halts for a Debug Assertion Failure in
> dbgheap.c.

> If I run the release version of the program with the debug version of the
> DLL all works fine.

> It's really a code problem or a wrong project setting ?

> Thanks in adavnce



Sat, 25 May 2002 03:00:00 GMT  
 Debug OK, Release NOT!
The whole Release vs Debug build dialogs that Microsoft started putting in
their tools a while back has to be the result of a mis-guided product
manager who was promoted from an entry level marketing position. I've
personally done lots of time and mission critical debugging projects for
clients on the verge of losing their jobs because of this release/debug
nonsense. You should only ever build debug versions of anything. When you're
satisfied that the product meets its requirements (on retail AND debug
builds of windows), run the binaries through a script that'll strip it and
then ship it. Even if you have only one difference (no matter how minor)
between your so-called release and debug builds, you're asking for trouble.
Just be happy that your little problem has been so kind as to showup early
(ie before full deployment), if it shows up later its so expensive that most
companies just suffer in silence.

Please dont confuse retail/debug binary builds with retail and debug/checked
verions of the OS, you should always include the debug OS in testing, if you
can. Btw, if you have a jerk for a boss and want to get him (her?) fired,
write a moderately complicated multithreaded application, and then claim the
boss instructed you to NOT test it on a multi-processor box, because that
would be a waste of time.


Quote:
> The project is a DLL.

> The test program that uses this dll works fine in Debug version (which
> includes the debug version of the DLL) but in the release version (which
> uses the Release DLL) stops because "...memory could not be written".

> If I build the release version of the DLL with the MDd option (instead of
> MD), then the release version of the test program (which still uses the
> Release version of the dll) halts for a Debug Assertion Failure in
> dbgheap.c.

> If I run the release version of the program with the debug version of the
> DLL all works fine.

> It's really a code problem or a wrong project setting ?

> Thanks in adavnce



Sun, 26 May 2002 03:00:00 GMT  
 Debug OK, Release NOT!
There a multitude of problems as folks have pointed out.  Try building your
debug app with /GZ (Visual 6.0 only) option.  See if that will help.
Aman

Quote:
> The project is a DLL.

> The test program that uses this dll works fine in Debug version (which
> includes the debug version of the DLL) but in the release version (which
> uses the Release DLL) stops because "...memory could not be written".

> If I build the release version of the DLL with the MDd option (instead of
> MD), then the release version of the test program (which still uses the
> Release version of the dll) halts for a Debug Assertion Failure in
> dbgheap.c.

> If I run the release version of the program with the debug version of the
> DLL all works fine.

> It's really a code problem or a wrong project setting ?

> Thanks in adavnce



Sun, 26 May 2002 03:00:00 GMT  
 Debug OK, Release NOT!
Charlie,

Depending on what you mean by 'You should only ever build debug
versions of anything" I either disagree or strongly agree.

Part of the problem is that the meaning of 'release vs debug' is overloaded.
The release build is typically an optimized build, which you want for your
customers but don't want when you're writing new code, because it is much
harder to debug. This difference is a valid one.

Unfortunately, another frequent difference between release and debug builds
is that release builds have debugging information disabled. That is stupid.
It is tragic that Microsoft defaults to having debug information disabled in
release builds.

It should be obvious that it is critically important that you be able to
debug the code that you ship to your customers - ultimately it's the only
code that matters. Therefore you _must_ enable debugging information for
release builds. Since the debugging information is stored in a separate file,
this does not mean that you have to ship it to your customers. If you add
the /OPT:REF option to the linker then enabling debug information only
increases your executable size by about 60 bytes - enough space to
hold the name of your .pdb file.

In short: if your release mode app crashes, run it under the de{*filter*} and
find out why. That will always be the answer.

Quote:

> The whole Release vs Debug build dialogs that Microsoft started putting in
> their tools a while back has to be the result of a mis-guided product
> manager who was promoted from an entry level marketing position. I've
> personally done lots of time and mission critical debugging projects for
> clients on the verge of losing their jobs because of this release/debug
> nonsense. You should only ever build debug versions of anything. When you're
> satisfied that the product meets its requirements (on retail AND debug
> builds of windows), run the binaries through a script that'll strip it and
> then ship it. Even if you have only one difference (no matter how minor)
> between your so-called release and debug builds, you're asking for trouble.
> Just be happy that your little problem has been so kind as to showup early
> (ie before full deployment), if it shows up later its so expensive that most
> companies just suffer in silence.

> Please dont confuse retail/debug binary builds with retail and debug/checked
> verions of the OS, you should always include the debug OS in testing, if you
> can. Btw, if you have a jerk for a boss and want to get him (her?) fired,
> write a moderately complicated multithreaded application, and then claim the
> boss instructed you to NOT test it on a multi-processor box, because that
> would be a waste of time.



> > The project is a DLL.

> > The test program that uses this dll works fine in Debug version (which
> > includes the debug version of the DLL) but in the release version (which
> > uses the Release DLL) stops because "...memory could not be written".

> > If I build the release version of the DLL with the MDd option (instead of
> > MD), then the release version of the test program (which still uses the
> > Release version of the dll) halts for a Debug Assertion Failure in
> > dbgheap.c.

> > If I run the release version of the program with the debug version of the
> > DLL all works fine.

> > It's really a code problem or a wrong project setting ?

> > Thanks in adavnce

--
.Bruce Dawson, Cavedog Entertainment.
Makers of Total Annihilation - http://www.*-*-*.com/


Sun, 26 May 2002 03:00:00 GMT  
 Debug OK, Release NOT!
My motto is: Don't fight mother nature, you always lose.

The build that you ship should be the build that you tested and debugged
during development. I see that your in the {*filter*} industry, and thus you
would be in the 0.01% of developers where maximum optimization would
actually be beneficial. However the other 99.99% of the world, imho,
shouldn't engage in the retail vs. debug folly. I have literally showed up
onsite, after the development team from major system integrators have packed
their bags, only to find out they spent 30% of there budget testing a build
a didn't even deliver, ie the so-called debug build.

Bottom line is you should only ever ship the build that you tested. If you
want to enable max optimizations, which in most cases only complicates
things, then you should turn them during your product/project's testing
phase. And no, one certainly doesn't have to suffer with optimization during
simple developer unit/functional testing. But you should absolutely leave in
code for sanity checks, assertions, data structure dumps in a released
version, if only hidden behind a command line flag or some other trigger.
Users deserve sw that works, and if it doesn't work, then the developers
should have enough breadcrumbs in their app to help themselve solve the
problem. The idea that users should have to collect a watson, or write down
the jibberish (to them) of a BSOD is total nonsense.


Quote:
> Charlie,

> Depending on what you mean by 'You should only ever build debug
> versions of anything" I either disagree or strongly agree.

> Part of the problem is that the meaning of 'release vs debug' is
overloaded.
> The release build is typically an optimized build, which you want for your
> customers but don't want when you're writing new code, because it is much
> harder to debug. This difference is a valid one.

> Unfortunately, another frequent difference between release and debug
builds
> is that release builds have debugging information disabled. That is
stupid.
> It is tragic that Microsoft defaults to having debug information disabled
in
> release builds.

> It should be obvious that it is critically important that you be able to
> debug the code that you ship to your customers - ultimately it's the only
> code that matters. Therefore you _must_ enable debugging information for
> release builds. Since the debugging information is stored in a separate
file,
> this does not mean that you have to ship it to your customers. If you add
> the /OPT:REF option to the linker then enabling debug information only
> increases your executable size by about 60 bytes - enough space to
> hold the name of your .pdb file.

> In short: if your release mode app crashes, run it under the de{*filter*} and
> find out why. That will always be the answer.


> > The whole Release vs Debug build dialogs that Microsoft started putting
in
> > their tools a while back has to be the result of a mis-guided product
> > manager who was promoted from an entry level marketing position. I've
> > personally done lots of time and mission critical debugging projects for
> > clients on the verge of losing their jobs because of this release/debug
> > nonsense. You should only ever build debug versions of anything. When
you're
> > satisfied that the product meets its requirements (on retail AND debug
> > builds of windows), run the binaries through a script that'll strip it
and
> > then ship it. Even if you have only one difference (no matter how minor)
> > between your so-called release and debug builds, you're asking for
trouble.
> > Just be happy that your little problem has been so kind as to showup
early
> > (ie before full deployment), if it shows up later its so expensive that
most
> > companies just suffer in silence.

> > Please dont confuse retail/debug binary builds with retail and
debug/checked
> > verions of the OS, you should always include the debug OS in testing, if
you
> > can. Btw, if you have a jerk for a boss and want to get him (her?)
fired,
> > write a moderately complicated multithreaded application, and then claim
the
> > boss instructed you to NOT test it on a multi-processor box, because
that
> > would be a waste of time.



> > > The project is a DLL.

> > > The test program that uses this dll works fine in Debug version (which
> > > includes the debug version of the DLL) but in the release version
(which
> > > uses the Release DLL) stops because "...memory could not be written".

> > > If I build the release version of the DLL with the MDd option (instead
of
> > > MD), then the release version of the test program (which still uses
the
> > > Release version of the dll) halts for a Debug Assertion Failure in
> > > dbgheap.c.

> > > If I run the release version of the program with the debug version of
the
> > > DLL all works fine.

> > > It's really a code problem or a wrong project setting ?

> > > Thanks in adavnce

> --
> .Bruce Dawson, Cavedog Entertainment.
> Makers of Total Annihilation - http://www.*-*-*.com/



Mon, 27 May 2002 03:00:00 GMT  
 Debug OK, Release NOT!
Interesting point.  We build both debug and release versions, and make use
of both.  For the most part developers use the debug build for testing &
debugging.  Testers use a 70/30 split of debug/release for most of the
product cycle, but then reverse the ratio towards the end of the product
cycle.  We also run many automated tests on our code -- some before checking
in, some daily, and some less often.  All automated tests are run on both
debug & release builds.

Perhaps our debug & release builds are more different than yours.  We
include extensive assert()s and other runtime checks in our debug builds,
which has two significant side effects.  The first is, of course,
performance -- the difference is quite significant.  It's more than enough
to be a burden on our users.

The second is stability -- the paranoid nature of the debug build causes it
to fail more often than release, so that we might catch problems that may
not otherwise appear in testing.

I agree with the note below about using checked builds of the OS for some
testing.  Any tool that you can use to help verify your product is one you
should take advantage of.  They find bugs quickly, easily, and cheaply, when
compared to manual testing by a human.

-Jay


Quote:
> My motto is: Don't fight mother nature, you always lose.

> The build that you ship should be the build that you tested and debugged
> during development. I see that your in the {*filter*} industry, and thus you
> would be in the 0.01% of developers where maximum optimization would
> actually be beneficial. However the other 99.99% of the world, imho,
> shouldn't engage in the retail vs. debug folly. I have literally showed up
> onsite, after the development team from major system integrators have
packed
> their bags, only to find out they spent 30% of there budget testing a
build
> a didn't even deliver, ie the so-called debug build.

> Bottom line is you should only ever ship the build that you tested. If you
> want to enable max optimizations, which in most cases only complicates
> things, then you should turn them during your product/project's testing
> phase. And no, one certainly doesn't have to suffer with optimization
during
> simple developer unit/functional testing. But you should absolutely leave
in
> code for sanity checks, assertions, data structure dumps in a released
> version, if only hidden behind a command line flag or some other trigger.
> Users deserve sw that works, and if it doesn't work, then the developers
> should have enough breadcrumbs in their app to help themselve solve the
> problem. The idea that users should have to collect a watson, or write
down
> the jibberish (to them) of a BSOD is total nonsense.



> > Charlie,

> > Depending on what you mean by 'You should only ever build debug
> > versions of anything" I either disagree or strongly agree.

> > Part of the problem is that the meaning of 'release vs debug' is
> overloaded.
> > The release build is typically an optimized build, which you want for
your
> > customers but don't want when you're writing new code, because it is
much
> > harder to debug. This difference is a valid one.

> > Unfortunately, another frequent difference between release and debug
> builds
> > is that release builds have debugging information disabled. That is
> stupid.
> > It is tragic that Microsoft defaults to having debug information
disabled
> in
> > release builds.

> > It should be obvious that it is critically important that you be able to
> > debug the code that you ship to your customers - ultimately it's the
only
> > code that matters. Therefore you _must_ enable debugging information for
> > release builds. Since the debugging information is stored in a separate
> file,
> > this does not mean that you have to ship it to your customers. If you
add
> > the /OPT:REF option to the linker then enabling debug information only
> > increases your executable size by about 60 bytes - enough space to
> > hold the name of your .pdb file.

> > In short: if your release mode app crashes, run it under the de{*filter*}
and
> > find out why. That will always be the answer.


> > > The whole Release vs Debug build dialogs that Microsoft started
putting
> in
> > > their tools a while back has to be the result of a mis-guided product
> > > manager who was promoted from an entry level marketing position. I've
> > > personally done lots of time and mission critical debugging projects
for
> > > clients on the verge of losing their jobs because of this
release/debug
> > > nonsense. You should only ever build debug versions of anything. When
> you're
> > > satisfied that the product meets its requirements (on retail AND debug
> > > builds of windows), run the binaries through a script that'll strip it
> and
> > > then ship it. Even if you have only one difference (no matter how
minor)
> > > between your so-called release and debug builds, you're asking for
> trouble.
> > > Just be happy that your little problem has been so kind as to showup
> early
> > > (ie before full deployment), if it shows up later its so expensive
that
> most
> > > companies just suffer in silence.

> > > Please dont confuse retail/debug binary builds with retail and
> debug/checked
> > > verions of the OS, you should always include the debug OS in testing,
if
> you
> > > can. Btw, if you have a jerk for a boss and want to get him (her?)
> fired,
> > > write a moderately complicated multithreaded application, and then
claim
> the
> > > boss instructed you to NOT test it on a multi-processor box, because
> that
> > > would be a waste of time.



> > > > The project is a DLL.

> > > > The test program that uses this dll works fine in Debug version
(which
> > > > includes the debug version of the DLL) but in the release version
> (which
> > > > uses the Release DLL) stops because "...memory could not be
written".

> > > > If I build the release version of the DLL with the MDd option
(instead
> of
> > > > MD), then the release version of the test program (which still uses
> the
> > > > Release version of the dll) halts for a Debug Assertion Failure in
> > > > dbgheap.c.

> > > > If I run the release version of the program with the debug version
of
> the
> > > > DLL all works fine.

> > > > It's really a code problem or a wrong project setting ?

> > > > Thanks in adavnce

> > --
> > .Bruce Dawson, Cavedog Entertainment.
> > Makers of Total Annihilation - http://www.*-*-*.com/



Tue, 28 May 2002 03:00:00 GMT  
 Debug OK, Release NOT!
One thing I haven't noticed anyone point out in this thread is that maybe the
release build doesn't work because the Microsoft optimizer is busted...

Prior to VC++ 6.0 I couldn't hardly build "hello world" and have it work
right when optimized, but I did notice that several of my programs which
wouldn't work correctly optimized finally started working when I tried
building them optimized with 6.0 (though I have wondered if Microsoft really
fixed their optimizer bugs or just disabled the optimizer even if you turn
the option on :-).

--

Concurrent Computers, Ft. Lauderdale, FL    \\\\     this troublesome
Me: http://home.att.net/~Tom.Horsley/          \\\\     autoconf?
Project Vote Smart: http://www.vote-smart.org     \\\\    !!!!!



Tue, 28 May 2002 03:00:00 GMT  
 Debug OK, Release NOT!
Believe it or not, it's possible to write code that breaks under
optimization without it being the fault of the optimizer.  I'm not
saying that the optimizer doesn't have bugs, it does, but it's not
always the optimizers fault.


Quote:
> One thing I haven't noticed anyone point out in this thread is that
maybe the
> release build doesn't work because the Microsoft optimizer is
busted...

> Prior to VC++ 6.0 I couldn't hardly build "hello world" and have it
work
> right when optimized, but I did notice that several of my programs
which
> wouldn't work correctly optimized finally started working when I
tried
> building them optimized with 6.0 (though I have wondered if
Microsoft really
> fixed their optimizer bugs or just disabled the optimizer even if
you turn
> the option on :-).

> --

me of
> Concurrent Computers, Ft. Lauderdale, FL    \\\\     this
troublesome
> Me: http://home.att.net/~Tom.Horsley/          \\\\     autoconf?
> Project Vote Smart: http://www.vote-smart.org     \\\\    !!!!!



Tue, 28 May 2002 03:00:00 GMT  
 Debug OK, Release NOT!
I agree. I've helped track down dozens of bugs that happen
only in release builds and only about three of them turned out
to be full blown optimizer bugs. Most or all of those were
fixed after I reported them.

There were a few caused by overly aggressive floating point
optimizations, but I put that in a separate category because those
problems (comparing a float to a double because the double
hasn't been written to its single precision memory location) are
a known risk of having "Improve float consistency" turned off.

Quote:

> Believe it or not, it's possible to write code that breaks under
> optimization without it being the fault of the optimizer.  I'm not
> saying that the optimizer doesn't have bugs, it does, but it's not
> always the optimizers fault.



> > One thing I haven't noticed anyone point out in this thread is that
> maybe the
> > release build doesn't work because the Microsoft optimizer is
> busted...

> > Prior to VC++ 6.0 I couldn't hardly build "hello world" and have it
> work
> > right when optimized, but I did notice that several of my programs
> which
> > wouldn't work correctly optimized finally started working when I
> tried
> > building them optimized with 6.0 (though I have wondered if
> Microsoft really
> > fixed their optimizer bugs or just disabled the optimizer even if
> you turn
> > the option on :-).

> > --

> me of
> > Concurrent Computers, Ft. Lauderdale, FL    \\\\     this
> troublesome
> > Me: http://home.att.net/~Tom.Horsley/          \\\\     autoconf?
> > Project Vote Smart: http://www.vote-smart.org     \\\\    !!!!!

--
.Bruce Dawson, Cavedog Entertainment.
Makers of Total Annihilation - http://www.cavedog.com


Tue, 28 May 2002 03:00:00 GMT  
 Debug OK, Release NOT!

Quote:

>I agree. I've helped track down dozens of bugs that happen
>only in release builds and only about three of them turned out
>to be full blown optimizer bugs. Most or all of those were
>fixed after I reported them.

Most often, the bugs I've run into which only happened in release
mode had to do with writing message-map entries by hand and getting
the wrong function signature, or not properly initializing a variable,
and having the variable just happen to contain the right value when
the program was built in debug mode.

 - Katy

--
Katy Mulvey             Please post replies to the newsgroup, thanks!
ORMEC Systems           Check out the VC++ FAQ: http://www.mvps.org/vcfaq
http://www.ormec.com    MVP/VC++



Tue, 28 May 2002 03:00:00 GMT  
 Debug OK, Release NOT!

Quote:
>Believe it or not, it's possible to write code that breaks under
>optimization without it being the fault of the optimizer.  I'm not
>saying that the optimizer doesn't have bugs, it does, but it's not
>always the optimizers fault.

I'm aware of that, but it has never been the case with any problem I tracked
down with the Microsoft compilers, they have always been what any sane
person would call compiler bugs. Of course, when I have taken the hours to
carefully document in minute detail what the compiler was doing wrong and
provide example code to reproduce it, I've always gotten back a response
from Microsoft saying something like "Oh! That's not a compiler bug, the
optimizer is free to throw away any information it feels like". So if you go
by Microsoft's definition, then I guess I haven't had compiler bugs :-).

--

Concurrent Computers, Ft. Lauderdale, FL    \\\\     this troublesome
Me: http://home.att.net/~Tom.Horsley/          \\\\     autoconf?
Project Vote Smart: http://www.vote-smart.org     \\\\    !!!!!



Fri, 31 May 2002 03:00:00 GMT  
 Debug OK, Release NOT!
What "any sane person" thinks is a compiler bug and what actually is
one are often two different things.

I can't count the number of times a junior programmer has told me that
something is a bug in the compiler, only to have me prove them wrong.
Even senior programmers sometimes get caught up in their own code.
The usual excuse is "Well, it works without optimization".  That's not
good enough.


Quote:
> >Believe it or not, it's possible to write code that breaks under
> >optimization without it being the fault of the optimizer.  I'm not
> >saying that the optimizer doesn't have bugs, it does, but it's not
> >always the optimizers fault.

> I'm aware of that, but it has never been the case with any problem I
tracked
> down with the Microsoft compilers, they have always been what any
sane
> person would call compiler bugs. Of course, when I have taken the
hours to
> carefully document in minute detail what the compiler was doing
wrong and
> provide example code to reproduce it, I've always gotten back a
response
> from Microsoft saying something like "Oh! That's not a compiler bug,
the
> optimizer is free to throw away any information it feels like". So
if you go
> by Microsoft's definition, then I guess I haven't had compiler bugs
:-).

> --

me of
> Concurrent Computers, Ft. Lauderdale, FL    \\\\     this
troublesome
> Me: http://home.att.net/~Tom.Horsley/          \\\\     autoconf?
> Project Vote Smart: http://www.vote-smart.org     \\\\    !!!!!



Fri, 31 May 2002 03:00:00 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Debug OK, Release NOT!

2. Debug ok - Release not

3. Q: VC6 debug ok, release not

4. ATL COM client program using DAO compiles and links OK in Debug BUT NOT Release mode

5. STRCPY does not work in debug, Ok in release build

6. debug exe OK but release exe crashes

7. Debug version ok but release version problem

8. Debug build ok, release - unresolved external _main

9. Is it OK to mixing debug versions and release verions of MFC extension DLLs

10. Release build OK / Debug version crashes /ODBC /dbcore.cpp

11. Debug version Ok, Release version Failed

12. Debug version ok but release version problem

 

 
Powered by phpBB® Forum Software