Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* gdb crashes in Cygwin
@ 2008-10-12 13:41 Mike Ady
  2008-10-12 15:47 ` Paul Pluzhnikov
  0 siblings, 1 reply; 3+ messages in thread
From: Mike Ady @ 2008-10-12 13:41 UTC (permalink / raw)
  To: gdb

Hi,

I apologize for posting to this forum.  I tried the Cygwin forum, and
I got no response.

I am attempting to help the author of the giac/xcas program to solve
some problems that occur only on Cygwin.  According to the author,
"Giac/Xcas is a free computer algebra system for Windows, Mac OS X and
Linux/Unix."  The author works primarily on Linux, and I use his
program on Windows/Cygwin, hence the need for my help.

The program, running on its own, doesn't crash.  However, when I try
to run the program from gdb, gdb crashes.

I have read the part of the gdb manual dealing with bug reports, and I
have read "http://www.gnu.org/software/gdb/bugs/" but I can't yet
fulfill all of the requirements for submitting a bug report.  Can
anyone provide some advice on how to proceed?

The crash is repeatable.  It occurs while the program is initializing
but after main is called, and I am able to set a breakpoint at the
last statement executed by the program before the crash.  (It's a
simple call to "gettimeofday".)  A half dozen steps later (into the
Cygwin DLL), gdb crashes.

I have configured the Cygwin core dump routine "dumper.exe" to get a
crash dump.  The dump is over 50 megabytes.  (Indeed, the program
itself is over 50 megabytes.)  I have even tried to use gdb to analyze
the crash dump, but gdb crashes doing that too, (with the command line
"gdb /usr/bin/gdb.exe gdb.exe.core").

I have downloaded the latest version of the gdb sources and I have
built it.  It exhibits all of the same behavior:

$ /usr/local/bin/gdb
GNU gdb (GDB) 6.8.50.20081012-cvs
...
This GDB was configured as "i686-pc-cygwin".

Here is my environment information (I'm running Cygwin on Windows XP SP3):

$ uname -a
CYGWIN_NT-5.1 WHISTLER 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin

$ gcc -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with:
/usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose
--prefix=/usr --exec-prefix=/usr --sysconfd
ir=/etc --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d
,f77,pascal,java,objc --enable-nls --without-included-gettext
--enable-version-specific-runtime-libs --without-x --enable-libgcj
 --disable-java-awt --with-system-zlib --enable-interpreter
--disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm
 --disable-win32-registry --enable-sjlj-exceptions
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

$ gdb
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
...
This GDB was configured as "i686-pc-cygwin".

Is there anything else that I can/should do to tie this down a little better?

Thanks

Mike Ady


^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: gdb crashes in Cygwin
@ 2008-10-12 20:56 Mike Ady
  0 siblings, 0 replies; 3+ messages in thread
From: Mike Ady @ 2008-10-12 20:56 UTC (permalink / raw)
  To: gdb

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


^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-10-12 20:56 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-12 13:41 gdb crashes in Cygwin Mike Ady
2008-10-12 15:47 ` Paul Pluzhnikov
2008-10-12 20:56 Mike Ady

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox