Re: Problem with 6.3 and Cygwin

Re: Problem with 6.3 and Cygwin

[tbutler]

Just a quick note to indicate that after updating my sources from CVS as of
10-March-2005, I've been able to successfully build Insight on Cygwin for
the arm-elf target.

Regards,
Tim Butler

Re: Problem with 6.3 and Cygwin

[tbutler]

>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

Thanks for the suggestion - I'll update my tree and keep an eye on the gdb
list.

I didn't really want to live right on the bleeding edge of CVS, but when I
went looking for the latest stable version of Insight, it appeared that it
was 6.1. Given the number of patches for 6.1 that I saw discussed over the
last 10+ months, I wanted to start off with something more current.

If there is a more recent stable snapshot or CVS tag for "insight+dejagnu",
I'd appreciate knowing about it. When I went looking, I found version 6.3
of GDB, but no corresponding 6.3 Insight, and so decided to checkout
"insight+dejagnu" from CVS HEAD and give it a shot.

Thanks and best regards,
Tim

Re: Problem with 6.3 and Cygwin

[Christopher Faylor]

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

Problem with 6.3 and Cygwin

[tbutler]

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.

First of all, I noticed that the Target Settings menu item didn't work.
Based on a search of the archive, I confirmed that this was caused by
problems with the images/ and images2/ directories. Overwriting these with
an older copy corrects the problem (both 6.1 and 5.3 vintages seem to be
OK). As noted in other posts, it appears that some of the .gif files are
simply corrupt; viewing them with Windows Explorer reveals several that are
undisplayable.

Having overcome that hurdle, I found that Insight crashes when I do just
about anything (eg. open a symbol file, connect to target). Taking the
advice of an earlier archive message, I opened the console to launch a
debug window ("Tk ManagedWin::open DebugWin"), but this crashed upon
entering the command. I tried a simple "help" in the console with the same
results. I don't think this is a core GDB problem, because if I run Insight
with --interpreter=console, I can perform these actions successfully.

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