Re: Application disappears without any crash dump
On May 6, 6:18 am, Joseph M. Newcomer <newco...@flounder.com> wrote:
See below...
On 05 May 10 15:19:03 -0800, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wr=
ote:
In article
<1509753c-6b6d-4459-8db0-13597ede8...@h37g2000pra.googlegroups.com>,
rsharma.ch...@gmail.com (Rahul) writes:
Thanks Alf,
So infinite recursion and large stack based array's seems to be the
problem. But why does the default debugger not catch these crashes.
I even tried on the system where Visual Studio was installed, It also
failed to catch those exceptions (unless we run the program the inside
debugger itself)
Is there any way to catch these crashes without running the program in
the debugger, and why are they not caught by the debugger by default
(just for understanding the technical difficulty involved in this).
My favourite way of dealing with these things is to define a buffer
on either site of the local variables:
void myfunc ()
{
char buffer1[512];
****
Generally, a C++ programmer should never write a declaration of the fo=
rm
type name[compile-time-constant-expression];
Not even for local buffers; I tend to do
CByteArray buffer;
buffer.SetSize(512);
ReadFile(f, buffer.GetData(), (DWORD)buffer.GetSize(), &b=
ytesRead, NULL);
The data is not on the stack, and is automatically cleaned up when the va=
riable leaves
scope. You can do an analogous trick with std::vector<BYTE>. It is =
always best to use
the BYTE data type for input buffers, since it eliminates any potential c=
onfusion that
might arise when Unicode comes into play.
*****
.....> ... other local variables ...
char buffer2[512];
memset ((void *) buffer1, 0, sizeof (buffer1));
memset ((void *) buffer2, 0, sizeof (buffer2));
****
This code is alwyas deeply suspect. Why memset to 0 something that is=
going to be
overwritten by input data? Bad programming style, generally. And us=
e ::ZeroMemory
instead of the 1975 PDP-11 model taught by amateur teachers. Better st=
ill, don't do it at
all!
If the code is so badly written that the buffer MUST be zeroed out, note =
that I said "so
badly written". I find little excuse for doing the memset-to-zero as a=
substitute for
responsible programming.
joe
******> ... code ...
}
Often that's enough to stop the mysterious disappearances. You can
then check "buffer1" and "buffer2" at various points in the code to
see whether they suddenly become nonzero. That should catch simple
overflows, but a truly wild pointer could clobber the stack far
enough away that nothing bad happens until the program exits.
Still, it's a start...
****
Note that VS > 2003 will catch buffer overruns in debug mode; I fined no =
compelling reason
to use anitque versions of VS which have poor error detection in the marg=
inally-correct
compilers that compile a language similar to, but not actually, C++.
A cause no one has mentioned is the horrendous technique of putting exit(=
) calls into the
code to handle error conditions. This has never made sense in the hist=
ory of programming,
in any language; it was a stupid idea in C on the PDP-11 and a more st=
upid idea in C++
and Windows. I've caught a number of "the program just disappears" bug=
s by finding all
exit() calls under various guises.
joe
*****
Joseph M. Newcomer [MVP]
email: newco...@flounder.com
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm
I tried reproducing the issue and found that this happens sometimes
when the VM space exhausts. I was running the application in debugger
and at one point of time (When the virtual size was 1.84 GB) the
process suddenly hung, I tried breaking in the debugger but debugger
could not show any stack, Then I did a "Detach All" in VC++ debugger
and the process just vanished after 10-12 seconds.
As per the general behavior when some memory allocation fails then an
Access violation should happen which should get caught in the
debugger, but is there any way that memory exhaustion could cause the
application to vanish (may be depending on where the allocation
failure happened, perhaps in the kernel code etc.)
Regards
Rahul