Re: gdb crashes in Cygwin

["Mike Ady" <mike.ady2@gmail.com>]

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