Discussion:
Activating debugger in case of crash in program compiled from the command line
(too old to reply)
James Kanze
2009-05-17 14:32:08 UTC
Permalink
I'm currently porting a fairly large batch of code from Unix
(Solaris, Linux) to Windows, compiling from the command line.
One of the test programs crashes, causing the error Window to
pop-up. (I presume that this is like a core dump under Unix.)
In earlier versions of the system, the Window offered me the
option to enter the debugger (assuming Visual Studios C++ was
installed, which is the case); this one doesn't. So how can I
see where I'm crashing, and a trace of the stack?

FWIW: the command line used to compile the files is:

cl -c -Foc:/kanze/generated/tmp/testAscii.tst6128/component/
CodeGeneratorExecs/scangen/testScanner.obj -Fdc:/kanze/generated/tmp/
testAscii.tst6128/component/CodeGeneratorExecs/scangen/
testScanner.pdb -vmg -GR -Gy -EHs -Zc:forScope,wchar_t -J -nologo -
DNOMINMAX -DGB_EFmtDoesntWork -D_CRT_SECURE_NO_DEPRECATE -GS- -Zi -w -
D_DEBUG_ -Ic:/kanze/generated/tmp/testAscii.tst6128 -DIS_UTF8=false -
I. -I./conf/i80x86-win32-vc80 -Ic:/kanze/generated/include -Ic:/kanze/
generated/include/conf/i80x86-win32-vc80 -Tp testScanner.cc

(all on one line). The same for all of the other source files,
then:

cl -Fmc:/kanze/generated/tmp/testAscii.tst6128/component/
CodeGeneratorExecs/scangen/testScanner -Fd -Fec:/kanze/generated/tmp/
testAscii.tst6128/component/CodeGeneratorExecs/scangen/
testScanner.exe -vmg -GR -Gy -EHs -Zc:forScope,wchar_t -J -nologo -
DNOMINMAX -DGB_EFmtDoesntWork -D_CRT_SECURE_NO_DEPRECATE -GS- -Zi -w -
D_DEBUG_ -Ic:/kanze/generated/tmp/testAscii.tst6128 -DIS_UTF8=false -
I. -I./conf/i80x86-win32-vc80 -Ic:/kanze/generated/include -Ic:/kanze/
generated/include/conf/i80x86-win32-vc80 c:/kanze/generated/tmp/
testAscii.tst6128/component/CodeGeneratorExecs/scangen/
testErrorHandler.obj c:/kanze/generated/tmp/testAscii.tst6128/
component/CodeGeneratorExecs/scangen/testScanner.obj c:/kanze/
generated/tmp/testAscii.tst6128/component/CodeGeneratorExecs/scangen/
testToken.obj c:/kanze/generated/tmp/testAscii.tst6128/component/
CodeGeneratorExecs/scangen/testTokenMap.obj c:/kanze/generated/tmp/
testAscii.tst6128/component/CodeGeneratorExecs/scangen/ScannerBase.obj
c:/kanze/generated/lib/GabiProgMgt.lib c:/kanze/generated/lib/
GabiText.lib c:/kanze/generated/lib/GabiIO.lib c:/kanze/generated/lib/
GabiUtil.lib c:/kanze/generated/lib/GabiTest.lib c:/kanze/generated/
lib/GabiBase.lib

While there's probable some undefined behavior in my code which
causes this, unless I can get a stack walkback, and see exactly
where it's crashing, I can't start looking for it.

I'm running Window XP Family edition, with Service Pack 3
installed; the version of C++ is Visual Studios Visual C++ 2008
Express Edition.

--
James Kanze (GABI Software) email:***@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
j***@cix.compulink.co.uk
2009-05-17 16:06:28 UTC
Permalink
In article
Post by James Kanze
One of the test programs crashes, causing the error Window to
pop-up. (I presume that this is like a core dump under Unix.)
Not very much like it at all, really. It has in common with a core dump
that it's a default action when a program crashes in particular ways,
but that's about all.

You need to give up on assuming that things happen in the same way as
Solaris or Linux now; they are very different, and you're going to have
to go through a bit of a learning curve.
Post by James Kanze
In earlier versions of the system, the Window offered me the
option to enter the debugger (assuming Visual Studios C++ was
installed, which is the case); this one doesn't. So how can I
see where I'm crashing, and a trace of the stack?
Is the error window telling you anything about what the crash is? You
usually do get offered the debugger still these days: were you using an
Express Edition of Visual Studio when it worked?

A simple method of debugging such a problem is to start the Visual
Studio IDE, open the .EXE file, and select Debug=>Start debugging from
the menu. Note that by default the debugger will not catch most hardware
traps; you need to enable them with Debug=>Exceptions.
--
John Dallman ***@cix.co.uk
"C++ - the FORTRAN of the early 21st century."
James Kanze
2009-05-18 09:38:33 UTC
Permalink
Post by j***@cix.compulink.co.uk
In article
Post by James Kanze
One of the test programs crashes, causing the error Window
to pop-up. (I presume that this is like a core dump under
Unix.)
Not very much like it at all, really. It has in common with a
core dump that it's a default action when a program crashes in
particular ways, but that's about all.
Well, that's more or less what I meant. That my program had
done something bad, like trying to access unmapped memory.
Post by j***@cix.compulink.co.uk
You need to give up on assuming that things happen in the same
way as Solaris or Linux now; they are very different, and
you're going to have to go through a bit of a learning curve.
I'm aware that it's very different. I've installed a Unix-like
toolkit to attenuate the differences, but even then.
Post by j***@cix.compulink.co.uk
Post by James Kanze
In earlier versions of the system, the Window offered me the
option to enter the debugger (assuming Visual Studios C++ was
installed, which is the case); this one doesn't. So how can I
see where I'm crashing, and a trace of the stack?
Is the error window telling you anything about what the crash
is?
No. It was just offered the choice between aborting and sending
a message to Microsoft.
Post by j***@cix.compulink.co.uk
were you using an Express Edition of Visual Studio when it
worked?
I have the Express Edition installed, but the GUI certainly
wasn't active.
Post by j***@cix.compulink.co.uk
A simple method of debugging such a problem is to start the
Visual Studio IDE, open the .EXE file, and select Debug=>Start
debugging from the menu. Note that by default the debugger
will not catch most hardware traps; you need to enable them
with Debug=>Exceptions.
Well, I finally got into the debugger by creating a dummy
project in a temporary directory, then specifying the path to
the executable (and to the sources). I'd tried opening the
.exe, but IIRC, I got an error message to the effect that there
was no editor capable of handling that sort of file.

--
James Kanze (GABI Software) email:***@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Continue reading on narkive:
Loading...