Thanks for the quick response!

Greg Chicares wrote:
On 2007-1-23 16:51 UTC, Chris Trobridge wrote:
I've inherited an XP program that is built using g++ and mingw32 
(msys).  It is multi-threaded and uses stl containers extensively and 
some of boost (may (not) be relevant).  It also links libnet and wpdpack.

You could try libstdc++'s debug mode, by defining things like:


Whether to use the '_GLIBCXX' or '_GLIBCPP' variants depends on
the version of libstdc++, but I believe it does no harm to define
them all.
I'm just rebuilding with them now.

My big problem with debugging is that it crashes, printing the message 
"abnormal program termination" in the console window.

Do you know whether that message comes from the application
as opposed to the debugger?
I'm tempted to say neither, but it occurs when I run it in a console window, whether it's being run under gdb or not, so it's not the debugger.

I've tried using both gdb and MSVC6 to debug and neither appears capable 
of catching the exception at the point it happens, so I'm none the wiser 
as to the cause.

MSVC appears to lose contact altogether as I cannot kill the process 
under debug and XP requires a restart.

This does sound like a segfault. I've never been able to
crash 'xp' with code I've written myself; could this stem
from a bad call into a library that sidesteps the usual
hardware protection? Just a guess.
Sorry, I wasn't clear enough.  It doesn't crash XP and this is only an issue with debugging under MSVC.  What happens is that after the crash MSVC can't communicate with the process under debug.  However, I can't kill the process manually either - some sort of access denied message.  As this prevents further re-running of the process I have to reboot XP to continue debugging.

Any idea as to what might be happening to stop the debugger from 
catching the error?  I'd have thought that the debugger should catch 
segmentation faults, illegal instructions etc.

I'd guess that parts of the debugger or its data are being
overwritten. A program that can crash the operating system
could also crash a debugger.

You might try another debugging tool such as drmingw, but
I wouldn't hold out much hope for that.

Maybe the only thing that'll work is stepping through the
code manually to localize the problem.
That would be nice.  My experience with MSVC is that is doesn't appear to recognise the debug info produced g++.  I've not tried much in the way of single stepping with gdb yet.

Part of the problem is that it is multithreaded.  I managed to isolate some code I thought caused the issue - as in if I bypass it then the crash is avoided - but there's nothing wrong with that code.  In fact even after I modified that code such the it stopped crashing, modifying an unrelated bit of code brought it back.

I thought it might be stack corruption, but again in the end the evidence was against this and it appears to be crashing in another thread.

Again, merely adding some debugging output (cerr << ...) can alter the point at which the crash occurs.

So my main theories at the moment are that something is releasing memory prematurely to the heap and it's getting overwritten.  This could lead directly to a seg fault, or possibly a bad vtable pointer.  So it's frustrating that I don't even know what sort of exception is occurring!

Thanks again,