Re: Find rare bugs - SEH and c++ exception handling
- From: "Markus Hofer" <mh@xxxxxxxxxxx>
- Date: Mon, 1 May 2006 16:32:58 +0200
Thanks a lot for your answer. I have already lots of assertions in place.
Unfortunately the bug occurs only "on the read" it's not that easy (or
convenient) to run under the debugger (although I will do this as last
resort). As the problem seems to appear in a background thread which has
some real time requirements, I can't introduce MessageBoxes because they
would make the application unusable.
It really seems that I neet a lot of patience.
Markus
2) add ASSERTs to check pointers and array references
3) add MessageBoxes to keep track of the program so you can find where
in your code the symptom shows
4) patience. lots and lots of patience
<r_z_aret@xxxxxxxxxxxx> wrote in message
news:c51552h9a6r1nojlthfpk2u1qd09obrppi@xxxxxxxxxx
Such pain is more common than any of us would like to admit. The basiccritical
cause is often a bad pointer or code that cleans up an array
incorrectly. And the symptoms commonly occur far away from the actual
bug. Some common methods:
1) run under a debugger and hope the debug window provides sufficient
feedback. Adding calls to OutputDebugString will help
2) add ASSERTs to check pointers and array references
3) add MessageBoxes to keep track of the program so you can find where
in your code the symptom shows
4) patience. lots and lots of patience
I just used google (http://groups.google.com/advanced_group_search) to
look up
debug release
in this newsgroup and got 242 hits. I think at least a few provide
relevant and useful info.
On Fri, 28 Apr 2006 09:40:25 -0700, "Barry Bond [MS]"
<barrybo@xxxxxxxxxxxxx> wrote:
If the bug repros on the DeviceEmulator, then you might have some luck if
you configure the emulator to display its debug console window for serial
port 1. When the kernel detects an application exception, it logs
causesdata about the exception out to the device's serial port.
Barry
"Markus Hofer" <mh@xxxxxxxxxxx> wrote in message
news:u90stVsaGHA.4424@xxxxxxxxxxxxxxxxxxxxxxx
I'm currently hunting a "rare" bug in a MFC PocketPC program, which
thethe program to just "disapear" from the screen. I'm using VS2005 and
findprogram targets PocketPC 2003 devices. The same Executable also runs on
WM5
PocketPCs.
The bug is not reproducible and occours without user interaction (there
are
some background threads in the application). How can I find such a bug?
I checked lots of documentation and googled on the Web, but could not
Wastsongood method:
a) Postmortem debugging / Dr. Watson
On WM5 it seems to be possible to write a crash dump (resp. Dr.
sureLog) and to do
some postmortem debugging using the dump. Unfortunately all the
documentation I found
referenced Platform Builder but none mentioned VS2005. So I'm not
awhether it is at all
possible to do this with VS2005
b) Exception Handling
VS2005 supports SEH as well as C++ exception handling. SEH would
probably
report the crash,
but does not unmangel the stack (destructors are not called) which is
doesproblem in multithreaded
programs (locks!).
C++ exceptions are not really helpful to find this bug, because it
please indicate which newsgroup and message).not give you information about
the exception.
In the WIN32 Api there exists the function _set_se_translator that
allows
you to handle a SEH exception as
C++ exception. Unfortunately this function does not seem to exist for
the
PocketPC.
So whatever I tried, it did not work as expected. All ideas, comments,
recommendations and so ob are highly
appreciated.
Markus
-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and
Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com
.
- Prev by Date: Re: Find rare bugs - SEH and c++ exception handling
- Next by Date: Re: SQL Mobile
- Previous by thread: Re: Find rare bugs - SEH and c++ exception handling
- Index(es):
Relevant Pages
|
