From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15048 invoked by alias); 16 Jan 2009 15:13:27 -0000 Received: (qmail 15040 invoked by uid 22791); 16 Jan 2009 15:13:26 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Jan 2009 15:12:37 +0000 Received: (qmail 3647 invoked from network); 16 Jan 2009 15:12:35 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Jan 2009 15:12:35 -0000 From: Pedro Alves To: "Pierre Muller" Subject: Re: [BUG] Quit and "(running)" problem Date: Fri, 16 Jan 2009 15:13:00 -0000 User-Agent: KMail/1.9.10 Cc: "'Joel Brobecker'" , gdb-patches@sourceware.org References: <000001c9770e$5579c160$006d4420$@u-strasbg.fr> <200901152215.00564.pedro@codesourcery.com> <000001c977b8$061f6b60$125e4220$@u-strasbg.fr> In-Reply-To: <000001c977b8$061f6b60$125e4220$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901161513.10684.pedro@codesourcery.com> X-IsSubscribed: yes 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-01/txt/msg00382.txt.bz2 A Friday 16 January 2009 08:54:21, Pierre Muller wrote: > I can confirm that your patch fixed the simple > test case that I submitted in PR9747. Thank you. > Reading the patch, I was wondering about the > utility of the old_chain cleanup in fetch_inferior_event > function. But this is probably due to my > lack of comprehension of the cleanup chain mechanisms. > > Is it really possible to reach > do_cleanups (old_chain) > with something else that old_chain > as the top item on the cleanup list? Yes, there's a make_cleanup_restore_current_thread call there that adds a new cleanup to the chain. > I thought that all the cleanups where stored > as local variables, so that all cleanups > that were set in functions called while running any > code called from within the fetch_inferior_event > would be invalid data anyhow at that point, > as the stack might have been overwritten by calls to other functions. Some confusion here. Instead of trying to explain the basic mechanism and doing a lousy job at it, I suggest taking a look at the Cleanups section in internals manual, if you haven't already, which I think explains it quite nicelly: http://sourceware.org/gdb/current/onlinedocs/gdbint_15.html#SEC118 Another way to really understand cleanups is to step through the make_cleanup, do_cleanups and discard_cleanups functions, it looks scarrier than it is. In this particular case, we have: old_chain +----+- | +- (always run this, wether leaving with an exception or leaving succesfully) | ts_old_chain +-+- (only run if there's an exception) [do something that can throw] [ if we got pass it sucessfully, discard the cleanup chain ] /* No error, don't finish the thread states yet. */ discard_cleanups (ts_old_chain); So, at this point we have something like: old_chain +----+- | +- (always run this, wether leaving with an exception or leaving succesfully) ts_old_chain (invalid, dangling pointer) /* Revert thread and frame. */ do_cleanups (old_chain); This statement runs the cleanup. ( I mentioned doing a lousy job explaining it. ) -- Pedro Alves