From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15568 invoked by alias); 10 Mar 2005 13:33:51 -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 14996 invoked from network); 10 Mar 2005 13:32:58 -0000 Received: from unknown (HELO noteszar.caf.es) (212.81.217.14) by sourceware.org with SMTP; 10 Mar 2005 13:32:58 -0000 Received: from cafbea_2.caf.es ([172.20.10.84]) by noteszar.caf.es (Lotus Domino Release 6.0) with ESMTP id 2005031014305765-701 ; Thu, 10 Mar 2005 14:30:57 +0100 Sensitivity: Subject: Problem with 6.3 and Cygwin To: insight@sources.redhat.com Message-ID: From: tbutler@caf.net Date: Thu, 10 Mar 2005 13:33:00 -0000 MIME-Version: 1.0 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 X-SW-Source: 2005-q1/txt/msg00058.txt.bz2 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=3Dconsole, 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=3D0x6865b8, old_chain=3D0x1061c6e0) at /Insight_2005-07-Mar/src/gdb/utils.c:351 351 *pmy_chain =3D ptr->next; /* Do this first incase recursion */ (gdb) bt #0 do_my_cleanups (pmy_chain=3D0x6865b8, old_chain=3D0x1061c6e0) at /Insight_2005-07-Mar/src/gdb/utils.c:351 #1 0x00409329 in do_cleanups (old_chain=3D0x1061c6e0) at /Insight_2005-07-Mar/src/gdb/utils.c:317 #2 0x0040b3c8 in vfprintf_filtered (stream=3D0x1024af60, format=3D0x60a290 "List of classes of %scommands:\n\n", args=3D0x22dac8 "=D4=DA\"") at /Insight_2005-07-Mar/src/gdb/utils.c:2159 #3 0x0040b4af in fprintf_filtered (stream=3D0x1024af60, format=3D0x60a290 "List of classes of %scommands:\n\n") at /Insight_2005-07-Mar/src/gdb/utils.c:2191 #4 0x0042798b in help_list (list=3D0x10226278, cmdtype=3D0x609fd0 "", class=3Dall_classes, stream=3D0x1024af60) at /Insight_2005-07-Mar/src/gdb/cli/cli-decode.c:837 #5 0x00427919 in help_cmd (command=3D0x0, stream=3D0x1024af60) 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