From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-61204-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 6899 invoked by alias); 16 Jan 2009 08:55:29 -0000
Received: (qmail 6891 invoked by uid 22791); 16 Jan 2009 08:55:29 -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 08:54:48 +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 n0G8sHkK070620           ; Fri, 16 Jan 2009 09:54:17 +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 n0G8sH2B006465            ; Fri, 16 Jan 2009 09:54:17 +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 n0G8sHeg096628 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)           ; Fri, 16 Jan 2009 09:54:17 +0100 (CET) (envelope-from muller@ics.u-strasbg.fr)
From: "Pierre Muller" <muller@ics.u-strasbg.fr>
To: "'Pedro Alves'" <pedro@codesourcery.com>
Cc: "'Joel Brobecker'" <brobecker@adacore.com>, <gdb-patches@sourceware.org>
References: <000001c9770e$5579c160$006d4420$@u-strasbg.fr> <20090115135901.GI24105@adacore.com> <000001c9772a$a1fb69f0$e5f23dd0$@u-strasbg.fr> <200901152215.00564.pedro@codesourcery.com>
In-Reply-To: <200901152215.00564.pedro@codesourcery.com>
Subject: RE: [BUG] Quit and "(running)" problem
Date: Fri, 16 Jan 2009 08:55:00 -0000
Message-ID: <000001c977b8$061f6b60$125e4220$@u-strasbg.fr>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2009-01/txt/msg00374.txt.bz2

  I can confirm that your patch fixed the simple
test case that I submitted in PR9747.
As such I of course 

  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?
  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.


Pierre Muller
Pascal language support maintainer for GDB