Re: Debug vs Release...Some questions...Please Help...

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

OK, see below...
On 22 Dec 2005 15:04:03 -0800, "Solomon_Man" <solomon_man@xxxxxxxxx> wrote:

>Joe and all,
>
>Thanks for the Reply.
>
>The application I am working on started out as a idea about 3-4 years
>ago by a programmer that has long left my company I work for. When he
>left the company he had created a working prototype but when he was
>dismissed the project was put on hold.
>
>Forward 3 or so years...
>
>When I came to the company I began immediately on the project which I
>completely went through to get a quick understanding of what the
>application was doing. From there I documented every function and set
>out to document any new functionality that they wished to have. I
>continued on with documentation until it met the requirements of any
>new project that I or the company would start.
>
>The application originally began as a Dialog application that had a
>System tray icon with a dynamic menu. So the user would right click on
>the system tray icon, which would bring up a popup menu, they would
>then select a value (menu button) and then get the corresponding
>dialog. Pretty straight forward application.
****
Yes. I have a couple like this. They work pretty well.
****
>
>The new application has the above functionality plus a Window that
>would show and hide based on a timer. This Window must be able to
>display HTML. So I started anew with a SDI application that inherits
>its view from the CHTMLView Class. I then added the System Tray Icon,
>the popup menu, dialogs, and a few utility classes to the application
>from the original application. The Window is hidden
>(ShowWindow(SW_HIDE))when the application first starts and then when
>the window is needed it is just ShowWindow(SW_Show) to un hide.
>
>The uninitialized strings were char * which I initialized and or used
>CStrings to clean up. I have been using CStrings for all new
>development.
>
>The application works fine in Release but in Debug it gives me a user
>exception.
****
It is almost certainly a bug. Note that the debug heap is quite different from the
release heap, so heap damage will have different manifestations in each. Thus, a bug
which clobbers something innocuous in the release version might do significant damage in
the debug version. That's the easy scenario. The bad scenario is the opposite one: a bug
that does harmless damage in the debug version does serious damage in the release version.

Back in 1981, when I was the senior software developer in a company, I instituted a policy
which was still in effect twenty years later when the company was sold: if there is a
storage damage bug, you drop everything immediately and find it and fix it.

Now, there's a couple strategies (I had built the heap allocator, so I'd heavily
instrumented it. Microsoft has essentially done what I did over 20 years ago, and you can
take advantage of it).

First, add something to your InitInstance like this:

ASSERT(_heapchk() == _HEAPOK);

If there is already damage to the heap, this assert will fail. Then you can start to
carve away at pieces trying to find which static constructor or DLL has done you in. If
this succeeds, put one right before the ParseCommandLine call. If it fails, you know the
damage happened in between. If it succeeds, life gets a lot more complex, and you will
end up single-stepping into ParseCommandLine.
****
>
>As I am a novice in MFC executables;
>
>Does the above application that I have created seem reasonable?
>
>Am I going about it the right way? (assuming that I had all this base
>code to begin with)
****
Storage damage bugs are elusive and difficult to deal with. They are among the most
dangerous and annoying bugs that you can have. C++ exacerbates this because static
constructors can do such damage, and this is very difficult in most environments to track
down. I have actually had to single-step in assembly mode looking for these. They are
even more disastrous if there is a static constructor in a DLL, because these are nearly
impossible to single-step into. So indirect methods, such as adding that ASSERT to each
DllMain help (note that a failure in DllMain doesn't necessarily mean that DLL is guilty,
although it is suggestive; the problem with storage damage bugs is that the damage can be
done billions of instructions before the access fault or assertion failure happen).

The best way to avoid these is to be *extremely* careful. Look for memcpy, strcpy,
strcat, _tcscpy, _tcscat, sprintf and similar dangerous (and ideally obsolete) calls. When
possible, use the strsafe library (one of the interesting phenomena of switching to
strsafe is that you discover all the places where the length is trusted but not known!).
Next, make sure every malloc or new is tested for validity, because it could be some
allocation is failing during a constructor (for whatever reason, although in fact this is
a low-likelihood scenario). Look for uninitialized pointers in C++ classes allocated via
'new'. Look for uninitialized local variable pointers.

I truly hate these bugs, and one of the things I've learned over the years is how to svoid
them in the first place. Which doesn't help when you inherit a piece of code several
years old, which is how I keep my skills up in dealing with this kind of bug.
****
>
>Is there any common pitfalls that could occur when converting an
>application in this matter?
****
There are tons of pitfalls, some of which I listed above. The entire list is probably
equal to the factorial of the number of variables plus class members, so the trick is to
start carving away. The _heapchk() is the first and often most effective cut at looking
for these bugs. After that, things get dicey.
****
>
>I am open to any ideas or suggestions!
>
>Thanks for all your replies,
>Chris
>SolomonMan
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • 1.9.3 Patch Notes
    ... Eye for an Eye - This talent will now still do damage when the ... Fixed a bug with the quest "Glyphed Oaken Branch" that was having the ... Cause Insanity should now correctly target Hakkar's current target, ... Slightly increased the movement of Lethon's Spirit Shades. ...
    (alt.games.warcraft)
  • Re: Condo invaded by wharf borer beetles
    ... burrow into moist wood and lay their eggs. ... the way the condo building is only 3 years old and is all brick on the ... Bug appearing only indoors? ... That and another development that I read about had a great deal of water damage because ...
    (alt.home.repair)
  • Re: 1.8 Patch Notes
    ... of the spell will now automatically cast the highest eligible rank. ... Arcane Missiles - Fixed a bug where occasionally no missiles would appear and no damage would be dealt. ...
    (alt.games.warcraft)
  • Re: New York Times Accused of Toying with Treason
    ... The damage is that the US Government is no longer trustworthy. ... If you poll people "do you think it is OK for the NSA to bug ... you without a warrant" the vote might go the other way. ...
    (soc.retirement)
  • Windows Help Heap Overflow
    ... 3: Bug Impact Rate: Undefined ... There is a heap based buffer overflow in the rendering engine of .hlp files in winhlp32.exe which will allow some ... Therefor I release this Heap Overflow as another ... set ecx -> Top SE handler address ...
    (Bugtraq)