From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7740 invoked by alias); 19 Feb 2004 15:32:59 -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 7666 invoked from network); 19 Feb 2004 15:32:54 -0000 Received: from unknown (HELO coyote.egenera.com) (63.160.166.46) by sources.redhat.com with SMTP; 19 Feb 2004 15:32:54 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by coyote.egenera.com (Postfix) with ESMTP id CE985A0526; Thu, 19 Feb 2004 10:19:16 -0500 (EST) Received: from coyote.egenera.com ([127.0.0.1]) by localhost (coyote.egenera.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29452-06; Thu, 19 Feb 2004 10:19:13 -0500 (EST) Received: from hasufel.egenera.com (southeast.egenera.com [63.160.166.4]) by coyote.egenera.com (Postfix) with ESMTP id 50DB2A0517; Thu, 19 Feb 2004 10:19:13 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by hasufel.egenera.com (8.11.6/8.11.6) with ESMTP id i1JFSce07380; Thu, 19 Feb 2004 10:28:38 -0500 Subject: execute_control_command may not remove its cleanups From: Dave Allan Reply-To: da_gdb@egenera.com To: gdb@sources.redhat.com Content-Type: text/plain Organization: Egenera, Inc. Message-Id: <1077204518.1305.1192.camel@hasufel.egenera.com> Mime-Version: 1.0 Date: Thu, 19 Feb 2004 15:32:00 -0000 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at egenera.com X-SW-Source: 2004-02/txt/msg00241.txt.bz2 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? Dave