From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22642 invoked by alias); 15 Apr 2009 19:44:12 -0000 Received: (qmail 22634 invoked by uid 22791); 15 Apr 2009 19:44:11 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 15 Apr 2009 19:44:05 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n3FJi0oM004972; Wed, 15 Apr 2009 15:44:00 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n3FJhxer022799; Wed, 15 Apr 2009 15:43:59 -0400 Received: from opsy.redhat.com (vpn-13-166.rdu.redhat.com [10.11.13.166]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n3FJhwuM014098; Wed, 15 Apr 2009 15:43:58 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 5632750830B; Wed, 15 Apr 2009 13:43:56 -0600 (MDT) To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: Current GDB crashes when it sources Emacs's .gdbinit References: <83ocuxlopc.fsf@gnu.org> From: Tom Tromey Reply-To: tromey@redhat.com Date: Wed, 15 Apr 2009 19:44:00 -0000 In-Reply-To: <83ocuxlopc.fsf@gnu.org> (Eli Zaretskii's message of "Wed\, 15 Apr 2009 22\:08\:31 +0300") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00346.txt.bz2 >>>>> "Eli" == Eli Zaretskii writes: Eli> As far as I could see, it crashes when it reads this line of the Eli> .gdbinit file supplied with Emacs: Eli> if $tem[0] == 'w' && $tem[1] == 'i' && $tem[2] == 'n' && $tem[3] == 'd' Sorry about that. I'm sending the appended fix throughq regression testing. Eli> #0 0x00002ae92925956f in obstack_free () from /lib/libc.so.6 Eli> #1 0x000000000044ce70 in do_my_cleanups (pmy_chain=0x8ee2b8, Eli> old_chain=0xa2e3f0) at utils.c:389 [...] Eli> (in fact, the Eli> whole `struct obstack' pointed to by h looks garbled, at least to me): Eli> I tried to debug this, but as I'm not very familiar with that part of Eli> GDB (evaluate_expression, evaluate_subexp_c, and friends), I ran out Eli> of time before I could find the villain. So I'm posting the Eli> information here, in the hope that someone else could pick up where I Eli> left off. A situation where a cleanup is being called and the data is mangled often means that some piece of code installed a cleanup referring to a local variable and then forgot to manage the cleanup before a return. That turned out to be the situation here. If the cleanup function is unusual enough, a breakpoint in make_cleanup is the easy way to find the bad call. Tom diff --git a/gdb/c-lang.c b/gdb/c-lang.c index 0c9e4f8..1fd83a4 100644 --- a/gdb/c-lang.c +++ b/gdb/c-lang.c @@ -941,7 +941,10 @@ evaluate_subexp_c (struct type *expect_type, struct expression *exp, *pos += 2; if (noside == EVAL_SKIP) - return NULL; + { + do_cleanups (cleanup); + return NULL; + } if ((dest_type & C_CHAR) != 0) {