From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13268 invoked by alias); 19 Feb 2004 15:40:21 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13258 invoked from network); 19 Feb 2004 15:40:17 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 19 Feb 2004 15:40:17 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AtqHg-0006pD-5G; Thu, 19 Feb 2004 10:40:16 -0500 Date: Thu, 19 Feb 2004 15:40:00 -0000 From: Daniel Jacobowitz To: Dave Allan Cc: gdb@sources.redhat.com Subject: Re: execute_control_command may not remove its cleanups Message-ID: <20040219154016.GA24829@nevyn.them.org> Mail-Followup-To: Dave Allan , gdb@sources.redhat.com References: <1077204518.1305.1192.camel@hasufel.egenera.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1077204518.1305.1192.camel@hasufel.egenera.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00242.txt.bz2 On Thu, Feb 19, 2004 at 10:28:38AM -0500, Dave Allan wrote: > Hello, > > I ran into a reproducible segfault in gdb (v.5.3, but the offending code > is still present in the CVS tree I checked out this morning). I traced > the problemto the execute_control_command function in cli/cli-script.c. > > It appears that execute_control_command doesn't always do or discard the > cleanups it creates before returning, which is not right according to > the gdb internals docs. According to section 13.1 Cleanups, "Your > function should explicitly do or discard the cleanups it creates. > Failing to do this leads to non-deterministic behavior..." > > The problem is that the call to do_cleanups in execute_control_command > is conditional (cli/cli-script.c at line 430): > > if (old_chain) > do_cleanups (old_chain); > > So, if the cleanup_chain was null entering execute_control_command, then > old_chain will be null, and the call to do_cleanups doesn't happen. > > Removing the if statement, thus making the do_cleanups (old_chain) > unconditional eliminates the segfault. > > Unfortunately, the segfault occurred while I was using gdb run under the > "crash" kernel dump analysis tool, and it appears to me that under > normal gdb usage, cleanup_chain is never null going into > execute_control_command. Thus, do_cleanups is always executed and the > segfault never appears and I don't have a reproducible test case that > works against a vanilla build. > > However, it seems from code inspection and the gdb internals > documentation that the call to do_cleanups ought to be unconditional. > Does that seem right? No, instead, the cleanup chain should always have an item on it. If make_cleanup is not called then old_chain will remain NULL, and do_cleanups (NULL) means "do all cleanups", not "do nothing". It looks to me like command_handler is responsible for there always being a cleanup on the chain: old_chain = make_cleanup (null_cleanup, 0); but maybe I'm mistaken about that; it's a bit far down the tree. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer