This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb crashes in Cygwin
- From: "Mike Ady" <mike dot ady2 at gmail dot com>
- To: gdb at sourceware dot org
- Date: Sun, 12 Oct 2008 14:54:49 -0600
- Subject: Re: gdb crashes in Cygwin
Many thanks for your help Paul. I've been programming for many years,
but I'm a gdb newbie, so your comments are very helpful.
> Use GDB to debug GDB:
>
> gdb -ex 'set prompt (top) ' --args gdb dumper.exe
> (top) run
> (gdb) run
> # at this point, inferior gdb should crash, and you should
> # see (top) prompt
> (top) where
(That should be in a manual somewhere!)
There is just a little confusion, I think. "Dumper.exe" is the Cygwin
core dump utility. "Xcas.exe" is the program that I'm trying to
debug.
I tried the following command line. However, when I type "run" at the
(top) prompt, I don't get a (gdb) prompt, the inferior gdb runs all on
its own. Unfortunately, gdb crashed doing this too.
$ /usr/local/bin/gdb -ex 'set prompt (top) ' --args gdb xcas.exe
Next I tried:
> gdb -ex 'set prompt (top) ' --args gdb gdb gdb.exe.core
> (top) run
This actually worked. (I think I was missing a gdb when I tried this
without your help.) I see:
...
Loaded symbols for C:\WINDOWS\system32\winmm.dll
Reading symbols from /cygdrive/c/WINDOWS/system32/serwvdrv.dll...done.
Loaded symbols for C:\WINDOWS\system32\serwvdrv.dll
Reading symbols from /cygdrive/c/WINDOWS/system32/umdmxfrm.dll...done.
Loaded symbols for C:\WINDOWS\system32\umdmxfrm.dll
Reading symbols from /cygdrive/c/WINDOWS/system32/vpnt.dll...
Program received signal SIGSEGV, Segmentation fault.
coff_symfile_read (objfile=0x1444b70, mainline=0) at coffread.c:913
913 if (bfd_section->flags & SEC_CODE)
(top)print bfd_section
$1 = (asection *) 0x0
(top)list 903
898 sec = cs_to_section (cs, objfile);
899 tmpaddr = cs->c_value;
900 }
901 else
902 {
903 asection *bfd_section = cs_to_bfd_section (cs, objfile);
904 sec = cs_to_section (cs, objfile);
905 tmpaddr = cs->c_value;
906 /* Statics in a PE file also get relocated */
907 if (cs->c_sclass == C_EXT
(top)list
908 || cs->c_sclass == C_THUMBEXTFUNC
909 || cs->c_sclass == C_THUMBEXT
910 || (pe_file && (cs->c_sclass == C_STAT)))
911 tmpaddr += ANOFFSET (objfile->section_offsets, sec);
912
913 if (bfd_section->flags & SEC_CODE)
914 {
915 ms_type =
916 cs->c_sclass == C_EXT || cs->c_sclass ==
C_THUMBEXTFUNC
917 || cs->c_sclass == C_THUMBEXT ?
(top)print *objfile
$3 = {next = 0x0, name = 0xfc61e0
"/cygdrive/c/WINDOWS/system32/vpnt.dll", flags = 3, symtabs = 0x0,
psymtabs = 0x0,
...
Obviously, gdb crashes because it is dereferencing the null pointer
"bfd_section".
So what is "vpnt.dll"? It took some detective work. Years ago, I
installed a music editing program called Cakewalk Express. Another
program that I've never used, called Cakewalk Virtual Piano (and its
MIDI2 driver vpnt.dll) got installed with it. I never uninstalled
that program because it wasn't causing any harm, until now.
Windows has this feature, that allows DLL's to inject themselves into
every single process ever run on a system. That's how gdb ended up
being loaded with vpnt.dll. It's a useful feature for virus scanners
to make sure that every program is protected. (Gosh, that same
technique allows viruses to install themselves in every process ever
run on a system. Why is Apple is laughing?)
Rather than uninstall Cakewalk, (in case I need to do further testing
later), I used the SysInternals "movefile" utility to rename vpnt.dll
to vpnt.dll.sav. (A file can't normally be deleted or renamed while
it is loaded into a process.) After a reboot, gdb no longer crashes.
While my immediate problem is resolved, in this code, gdb is rather
nonchalant about checking pointers. I took a peek in
cs_to_bfd_section, and I didn't see anything obviously zeroing that
pointer. I'd guess that the COFF table in vpnt.dll is either
(unintentionally) malformed or corrupted. It might make sense for gdb
to check this pointer and halt symbol processing for the file if the
pointer is bad. (At this point, without more help, I don't really
have the skill to track into this much deeper.)
Thanks again,
Mike Ady