How can debugger cause a crash (VS6, C++ XP)

[Alan Williams-Key]

My program reads text files and converts them into binary data stored in
various CArray structures. When finished, it destroys the data with RemoveAt
or RemoveAll function calls. A user has reported that with his files the
program always crashes at the end and the stack trace in the crash dump shows
this to be caused by a RemoveAt or RemoveAll call. When I run the program
with his data it does exactly this. When I run under debug (release image,
run to suspect instruction) the program crashes in a completely different
place in the initial text file processing stage. Best I can see it happens on
a "new" call embedded within a SetAtGrow() call . How is this possible that
the program behaves so differently?

[David Lowndes]

Post by Alan Williams-Key
My program reads text files and converts them into binary data stored in
various CArray structures. When finished, it destroys the data with RemoveAt
or RemoveAll function calls. A user has reported that with his files the
program always crashes at the end and the stack trace in the crash dump shows
this to be caused by a RemoveAt or RemoveAll call. When I run the program
with his data it does exactly this. When I run under debug (release image,
run to suspect instruction) the program crashes in a completely different
place in the initial text file processing stage. Best I can see it happens on
a "new" call embedded within a SetAtGrow() call . How is this possible that
the program behaves so differently?

If the root problem is pseudo-random and not in itself fatal it's
possible for it to go unnoticed for an eon (in computer time) before
something more noticeable goes wrong.

If you were using a newer version of VC++ I'd recommend you to build
your debug version with all the run-time checking options enabled to
see if they can identify an earlier issue. You may find Boundschecker,
Purify, or other such programs will help you track down the issue.

Dave

[Alan Williams-Key]

Post by David Lowndes

Post by Alan Williams-Key
My program reads text files and converts them into binary data stored in
various CArray structures. When finished, it destroys the data with RemoveAt
or RemoveAll function calls. A user has reported that with his files the
program always crashes at the end and the stack trace in the crash dump shows
this to be caused by a RemoveAt or RemoveAll call. When I run the program
with his data it does exactly this. When I run under debug (release image,
run to suspect instruction) the program crashes in a completely different
place in the initial text file processing stage. Best I can see it happens on
a "new" call embedded within a SetAtGrow() call . How is this possible that
the program behaves so differently?

If the root problem is pseudo-random and not in itself fatal it's
possible for it to go unnoticed for an eon (in computer time) before
something more noticeable goes wrong.
If you were using a newer version of VC++ I'd recommend you to build
your debug version with all the run-time checking options enabled to
see if they can identify an earlier issue. You may find Boundschecker,
Purify, or other such programs will help you track down the issue.
Dave

(Third time of trying to reply to this - hope the system works this time)

Thanks for replying. I'm using VS6 as you noticed. If I run the debug
version (instead of the release version) there are no problems at all! Tried
to install the evaluation version of Purify but it wouldn't install! So the
question remains, how can running under the debugger change the program
behavior. If I knew the answer I might be able to postulate what teh problem
is. Any ideas?

Alan

[David Lowndes]

Post by Alan Williams-Key
Thanks for replying. I'm using VS6 as you noticed. If I run the debug
version (instead of the release version) there are no problems at all! Tried
to install the evaluation version of Purify but it wouldn't install! So the
question remains, how can running under the debugger change the program
behavior. If I knew the answer I might be able to postulate what teh problem
is. Any ideas?
Alan

Only vague ones, I don't recall the details. I *think* that running
under the debugger causes the OS heap allocation to do something
different.

Dave

[David Lowndes]

Post by David Lowndes
Only vague ones, I don't recall the details. I *think* that running
under the debugger causes the OS heap allocation to do something
different.

This might be the sort of thing I was thinking of:

http://msdn.microsoft.com/en-us/library/cc266414.aspx

Dave

[Ismo Salonen]

Post by Alan Williams-Key
My program reads text files and converts them into binary data stored in
various CArray structures. When finished, it destroys the data with RemoveAt
or RemoveAll function calls. A user has reported that with his files the
program always crashes at the end and the stack trace in the crash dump shows
this to be caused by a RemoveAt or RemoveAll call. When I run the program
with his data it does exactly this. When I run under debug (release image,
run to suspect instruction) the program crashes in a completely different
place in the initial text file processing stage. Best I can see it happens on
a "new" call embedded within a SetAtGrow() call . How is this possible that
the program behaves so differently?

Debugger changes a little bit memory allocation layout , so it sounds
like you have a rogue pointer. My crystal ball tells me that you are
using memory after it was freed. Or you are using pointer before it was
initialized.
Or you are mixing Debug and Release mode libraries.
Or you are freeing(delete/free) memory that is not obtained from
malloc/new.
Or you overwriting some buffer. Possiblitities are almost endless.

Attaching running application prevents the memory layout changes but
you still have memory errors.

ismo

[Ben Voigt [C++ MVP]]

Post by Alan Williams-Key
My program reads text files and converts them into binary data stored in
various CArray structures. When finished, it destroys the data with RemoveAt
or RemoveAll function calls. A user has reported that with his files the
program always crashes at the end and the stack trace in the crash dump shows
this to be caused by a RemoveAt or RemoveAll call. When I run the program
with his data it does exactly this. When I run under debug (release image,
run to suspect instruction) the program crashes in a completely different
place in the initial text file processing stage. Best I can see it happens on
a "new" call embedded within a SetAtGrow() call . How is this possible that
the program behaves so differently?

(psychic debugging activated, accuracy may be less than ideal)

You're writing past the *beginning* of a heap-allocated object, thus
trashing the internal heap pointers. Trying to free the object will almost
always cause trouble, but any allocation also can if it walks the heap
looking for empty space to use instead of increasing the heap size.

Post by Alan Williams-Key
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4512 (20091015) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4512 (20091015) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com