From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6896 invoked by alias); 16 Jan 2009 15:39:42 -0000 Received: (qmail 6884 invoked by uid 22791); 16 Jan 2009 15:39:41 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.151) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Jan 2009 15:39:05 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n0GFcvaH039526 ; Fri, 16 Jan 2009 16:38:57 +0100 (CET) Received: from mailserver.u-strasbg.fr (ms4.u-strasbg.fr [IPv6:2001:660:2402:d::13]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id n0GFcvG1097383 ; Fri, 16 Jan 2009 16:38:57 +0100 (CET) (envelope-from muller@ics.u-strasbg.fr) Received: from d620muller (www-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id n0GFcvhw091808 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 16 Jan 2009 16:38:57 +0100 (CET) (envelope-from muller@ics.u-strasbg.fr) From: "Pierre Muller" To: "'Pedro Alves'" Cc: "'Joel Brobecker'" , References: <000001c9770e$5579c160$006d4420$@u-strasbg.fr> <200901152215.00564.pedro@codesourcery.com> <000001c977b8$061f6b60$125e4220$@u-strasbg.fr> <200901161513.10684.pedro@codesourcery.com> In-Reply-To: <200901161513.10684.pedro@codesourcery.com> Subject: RE: [BUG] Quit and "(running)" problem Date: Fri, 16 Jan 2009 15:39:00 -0000 Message-ID: <007101c977f0$8efcd340$acf679c0$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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/msg00383.txt.bz2 Thanks for the explanations... =20=20 By the way, this also explains why I got troubles when I tried some code=20 with windows OS, where I added some debug informations using printf_unfiltered into the windows function that handles console control events. The problem was that even printf_unfiltered adds some cleanups, but this control function is executed in a newly created thread, which=20 leads to big troubles, if a second control event is generated... Pierre Muller Pascal language support maintainer for GDB =20=20 > -----Message d'origine----- > De=A0: Pedro Alves [mailto:pedro@codesourcery.com] > Envoy=E9=A0: Friday, January 16, 2009 4:13 PM > =C0=A0: Pierre Muller > Cc=A0: 'Joel Brobecker'; gdb-patches@sourceware.org > Objet=A0: Re: [BUG] Quit and "(running)" problem >=20 > 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. >=20 > Thank you. >=20 > > 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? >=20 > Yes, there's a make_cleanup_restore_current_thread call > there that adds a new cleanup to the chain. >=20 > > 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. >=20 > 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: >=20 > http://sourceware.org/gdb/current/onlinedocs/gdbint_15.html#SEC118 >=20 > 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. >=20 >=20 > In this particular case, we have: >=20 > old_chain +----+- > | > +- (always run this, wether > leaving with an exception or leaving succesfully) > | > ts_old_chain +-+- (only run if there's an > exception) >=20 > [do something that can throw] >=20 > [ if we got pass it sucessfully, discard the > cleanup chain ] >=20 > /* No error, don't finish the thread states yet. */ > discard_cleanups (ts_old_chain); >=20 > So, at this point we have something like: >=20 > old_chain +----+- > | > +- (always run this, wether > leaving with an exception or leaving succesfully) >=20 > ts_old_chain (invalid, dangling pointer) >=20 > /* Revert thread and frame. */ > do_cleanups (old_chain); >=20 > This statement runs the > cleanup. >=20 > ( I mentioned doing a lousy job explaining it. ) >=20 > -- > Pedro Alves