Thanks for the quick response!
Greg Chicares wrote:
I'm just rebuilding with them now.
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:
-D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC -D_GLIBCXX_CONCEPT_CHECKS
-D_GLIBCPP_DEBUG -D_GLIBCPP_DEBUG_PEDANTIC -D_GLIBCPP_CONCEPT_CHECKS
Whether to use the '_GLIBCXX' or '_GLIBCPP' variants depends on
the version of libstdc++, but I believe it does no harm to define
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
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?
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.
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.
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.
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.
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
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