From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27544 invoked by alias); 10 Mar 2005 14:28:55 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 27011 invoked from network); 10 Mar 2005 14:28:47 -0000 Received: from unknown (HELO cgf.cx) (66.30.17.189) by sourceware.org with SMTP; 10 Mar 2005 14:28:47 -0000 Received: by cgf.cx (Postfix, from userid 201) id 5FDAE13D1D4; Thu, 10 Mar 2005 09:28:47 -0500 (EST) Date: Thu, 10 Mar 2005 14:28:00 -0000 From: Christopher Faylor To: tbutler@caf.net, insight@sources.redhat.com Subject: Re: Problem with 6.3 and Cygwin Message-ID: <20050310142847.GB16211@gully.casa.cgf.cx> Reply-To: insight@sources.redhat.com Mail-Followup-To: tbutler@caf.net, insight@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-SW-Source: 2005-q1/txt/msg00059.txt.bz2 On Thu, Mar 10, 2005 at 02:41:47PM +0100, tbutler@caf.net wrote: >I've built Insight for the arm-elf target, using the sources from the CVS >tree as of 7-Mar-2005. My host environment is WinXP with Cygwin, using the >latest packages as of 8-March-2005. If you are going to be using gdb from cvs you would be well advised to track the gdb mailing lists. Cygwin has been broken in gdb for a while but Corinna Vinschen checked in a fix yesterday: http://sources.redhat.com/ml/gdb-patches/2005-03/threads.html#00145 cgf >Debugging the simple "help" scenario reveals the following trace: > >(gdb) run >Starting program: /gnutools/bin/arm-elf-insight.exe > >Program received signal SIGSEGV, Segmentation fault. >do_my_cleanups (pmy_chain=0x6865b8, old_chain=0x1061c6e0) > at /Insight_2005-07-Mar/src/gdb/utils.c:351 >351 *pmy_chain = ptr->next; /* Do this first incase recursion >*/ >(gdb) bt >#0 do_my_cleanups (pmy_chain=0x6865b8, old_chain=0x1061c6e0) > at /Insight_2005-07-Mar/src/gdb/utils.c:351 >#1 0x00409329 in do_cleanups (old_chain=0x1061c6e0) > at /Insight_2005-07-Mar/src/gdb/utils.c:317 >#2 0x0040b3c8 in vfprintf_filtered (stream=0x1024af60, > format=0x60a290 "List of classes of %scommands:\n\n", > args=0x22dac8 "??\"") at /Insight_2005-07-Mar/src/gdb/utils.c:2159 >#3 0x0040b4af in fprintf_filtered (stream=0x1024af60, > format=0x60a290 "List of classes of %scommands:\n\n") > at /Insight_2005-07-Mar/src/gdb/utils.c:2191 >#4 0x0042798b in help_list (list=0x10226278, cmdtype=0x609fd0 "", > class=all_classes, stream=0x1024af60) > at /Insight_2005-07-Mar/src/gdb/cli/cli-decode.c:837 >#5 0x00427919 in help_cmd (command=0x0, stream=0x1024af60) > at /Insight_2005-07-Mar/src/gdb/cli/cli-decode.c:744 >[ snip ] > >The 'pmy_chain' argument which do_my_cleanups() receives points to the >value zero, which ultimately leads to a null pointer dereference. It is >actually the address of the global variable 'cleanup_chain', which I found >gets overwritten with zero during the execution of vfprintf_filtered() (I'm >assuming that it shouldn't be 0). I followed the flow a bit, and found that >control arrives at gdbtk_fputs(), and the actual overwriting of the occurs >deep in the resulting flow of Tcl/Tk processing. > >Any suggestions as to what might be wrong, or where to investigate further, >would be greatly appreciated. > >Regards, >Tim > > > >