From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15629 invoked by alias); 12 Oct 2008 20:56:02 -0000 Received: (qmail 15620 invoked by uid 22791); 12 Oct 2008 20:56:01 -0000 X-Spam-Check-By: sourceware.org Received: from qb-out-1314.google.com (HELO qb-out-1314.google.com) (72.14.204.173) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 12 Oct 2008 20:54:52 +0000 Received: by qb-out-1314.google.com with SMTP id e19so1316159qbe.0 for ; Sun, 12 Oct 2008 13:54:49 -0700 (PDT) Received: by 10.181.144.11 with SMTP id w11mr3901992bkn.27.1223844889246; Sun, 12 Oct 2008 13:54:49 -0700 (PDT) Received: by 10.180.245.3 with HTTP; Sun, 12 Oct 2008 13:54:49 -0700 (PDT) Message-ID: <3d6b7a250810121354k76f714b4g7b041160fe5447fb@mail.gmail.com> Date: Sun, 12 Oct 2008 20:56:00 -0000 From: "Mike Ady" To: gdb@sourceware.org Subject: Re: gdb crashes in Cygwin MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00053.txt.bz2 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