From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 723 invoked by alias); 23 Jun 2008 20:50:30 -0000 Received: (qmail 687 invoked by uid 22791); 23 Jun 2008 20:50:29 -0000 X-Spam-Check-By: sourceware.org Received: from ns.surtec.de (HELO SurTec.com) (62.157.175.70) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 23 Jun 2008 20:50:09 +0000 Received: from [172.16.1.237] (unknown [61.47.26.18]) by SurTec.com (Postfix) with ESMTP id 6DAA8678764; Mon, 23 Jun 2008 22:50:05 +0200 (CEST) Cc: Dmitry Smirnov Message-Id: <0B94A1BC-59EB-44AD-B387-9051D0533E97@surtec.com> From: "Dr. Rolf Jansen" To: gdb@sourceware.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: How to catch GDB crash Date: Mon, 23 Jun 2008 20:50:00 -0000 References: X-Mailer: Apple Mail (2.924) X-IsSubscribed: yes 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-06/txt/msg00225.txt.bz2 Hi, Here comes a poor mans approach. 1. add in the file gdb/main.c at line 661 the following code: #if defined (POOR_MAN_DEBUG) printf_filtered ("[GDB PID %d]\n", getpid()); t0 = time(NULL); while ((diff = difftime(time(NULL), t0)) <= 60); #endif and at line 43 #if defined (POOR_MAN_DEBUG) #include double diff; time_t t0 = time(NULL); #endif 2. issue before the configure command: export CFLAGS="-g -O0 -DPOOR_MAN_DEBUG" export CXXFLAGS=$CFLAGS 3. configure and make your cross-686-pc-cygwin/arm-elf-gdb 4. start the cross-debugging session 5. now you have 60 seconds to attach your host-gdb to the just printed PID of your cross-gdb, and to set a reasonable breakpoint somewhere near to the location where you expect the crash to happen. 6. after 60 s the cross-gdb will continue running and your host-gdb shall stop the cross-gdb at the breakpoint that you set. 7. Now step through until the crash occurs. Hopefully this helps. Best regards Rolf Jansen Am 23.06.2008 um 23:31 schrieb Dmitry Smirnov: > Hi, > > I've encountered the very annoying problem with GDB. While > debugging, it crashes for some reason and I cannot catch this > moment. I have a possibility to attach to the running process with > another GDB, but it does not help. Perhaps, there is some way to > catch some system exception or something similar? > > I'm using a litle bit complex setup, so there is no much freedom (at > least I cannot simplify the situation). First, I'm debugging from > Eclipse (and it looks this crash happens only while running from > Eclipse, I've tried from commad line - there is no crash). The > debugger I'm using is cross-compiled arm-elf-gdb. It is compiled on > windows (i686) platform: > GNU gdb (GDB) 6.8.50.20080620 > ... > This GDB was configured as "--host=i686-pc-cygwin --target=arm-elf". > > I doubt this can be linked to GDB version. I recall I've seen this > crash earlier with arm-elf-gdb 6.5 from GNUARM. I was just skipped > this crash somehow but now I cannot continue my job. > > This arm-elf-gdb is running against skyeye simulator as a remote > target. > > As you can see there are many possibilities for mailfunctioning > software (Eclipse, GDB, skyeye). But the only way I can find the > root cause is to debug the crash in arm-elf-gdb. While crashing it > attempts to create the crashdump file, but it is incomplete and > Cygwin gdb cannot recognize it. Typically it contains just three > lines: > > Stack trace: > Frame Function Args > 0022E268 7C802532 (00000058 > > If attached, Cygwin GDB just reporting me: > Program exited with code 037777777777. > > Is there any way to stop arm-elf-gdb on some critical error? > > Dmitry > >