Re: debugging in release mode

See below...
On Mon, 5 Jun 2006 18:37:18 +0800, "Bill Brehm" <<don't want any spam>> wrote:

I have no doubt that it's a problem of mine and not of the compiler. My code
is new and relatively untested and the compiler has been tested for many
years. As long as the optimizing compiler is helping my bugs to appear, I
don't mind using it to help me find them. I don't really need optimization
for the sake of memory space or execution speed.

I will try your approach to this new mode. Is there a list anywhere that
shows the differences between the default debug mode and the default release
mode? The three things I am familiar with are debug info, optimization and
TRACE statements. I used to think that debug information was stored in the
executable and so the release mode was required send an executable without
source code inside. That misconception was corrected when i learned that
that the debug is stored in a separate (.pdb, I think) file.
****
Debug mode does several things.
- It turns off all optimizations
- It defines the _DEBUG symbol
- It initializes local variables to 0xCCCCCCCCC
- It initializes malloc/new heap allocations
- It overwrites heap data on a free/delete
- It uses a runtime that makes a lot more tests
It is the presence of the _DEBUG symbol that enables things like TRACE, ASSERT, and the
test on VERIFY, so in a release build that is unoptimized you will not have TRACE, ASSERT,
a test on VERIFY, any other code that depends on _DEBUG being defined; you will not have
local variables initialized, and you will have a very trusting heap. In addition, CString
in debug mode will allocate just the amount of space required, but in release mode, it
will allocate 64, 128, 256 or 512 byte strings to improve performance and reduce
fragmentation. I have no idea what you mean by "an executable with source code inside".
This was never true, on any system in history that I've worked on. The only difference
was the symbol table was in the .exe insted of being in a separate .pdb file. But the
source was never there.
*****

I am not using threads on purpose. But there is a frame grabber hardware and
software library that is included in my project and I believe it is using a
thread to alert me when an image has been captured. But it does not use MFC
and the most I will do from inside the alert is invalidate a rectangle on
the dialog application to update an image.
*****
How do you mean "to alert me"? Does it do a callback? Send a message? What?
*****

I have found that one source of crash is when UpdateWindow() is called from
inside an OnTimer() call. It doesn't crash the first few times. But when it
does crash, I see the this pointer for the main dialog of the dialog
application has changed from a sensible value to 0x401.
****
Actually, this is more likely due to something else clobbering the data. There's
something awfully suspicious about calling UpdateWindow from within an OnTimer, but I
don't think that's your problem. It sounds like a memory overwrite. The memory overwrite
can be triggered by some OnPaint handler of whatever window your are updating.

I'm not sure if _heapchk() works in the release version, but if it does, it might help.
Normally I'd write
ASSERT(_heapchk() == HEAPOK)
[or something very similar, I'm trying to do this from memory], but of course ASSERTs are
done in the nondebug version. So I'd probably add a symbol _DEBUGRELEASE which I would
use in the form
#ifdef _DEBUGRELEASE
#define MEMCHK() { \
if(_heapchk() != HEAPOK) \
{ \
CString s; \
s.Format(_T("%s (%d): Heap Check failed"),
__FILE__, __LINE__); \
AfxMessageBox(s); \
} \
}
#else
#define MEMCHK()
#endif
or something like that.
joe
*****

Thanks,

Bill

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:eql082t9hv8gq8smh6hp7jhv8kdcbvohul@xxxxxxxxxx
See my essay on suriving the release version, on my MVP Tips site. 99% of
the time what
you are seeing are errors in your own code that got masked by the
unoptimized code of a
debug build; the code was always wrong, but the damage it did was
harmless. It has been
many years since I've seen a genuine optimizer bug in a Microsoft
compiler, although it is
always a remote possibility.

Don't create a new configuration from debug mode; create it from a release
configuration
and then turn off optimizations and turn on generation of debug
information (you can't use
compile-and-go option here). Note that if you don't see the bug, it can
also indicate
that errors in your program are again being masked by having no
optimizations.

Are you using threads? There are lots of bugs that can show up on
multithreaded optimized
code that don't show up in multithreaded debug code, because the optimizer
makes
single-thread assumptions which you can violate.
joe

On Fri, 2 Jun 2006 15:51:53 +0800, "Bill Brehm" <<don't want any spam>>
wrote:

I have a program that runs well in debug mode. when i switch to release
mode
i get access violations. but of course i am thrown into a disassembly view
that tells me almost nothing about where the problem is. I guess it has to
do with optimization and how my code interacts with that. I would like
some
tips on how to find and fix this type of problem.

As a test, I created a new mode and copied from debug mode and then went
in
and switched off debug information in the compiler and linker. what else
would i have to switch off to protect the executable from containing
anything of the source code that the end customer should not be seeing? If
i
can't solve the problem in release mode, i'm thinking that the
optimizations
are really not that important to me.

thanks...

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Quantcast