Re: Problem with 6.3 and Cygwin

[Christopher Faylor <cgf-insight at sourceware dot org>]

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
>
>
>
>