From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9438 invoked by alias); 24 Feb 2004 16:47:15 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9424 invoked from network); 24 Feb 2004 16:47:15 -0000 Received: from unknown (HELO coyote.egenera.com) (63.160.166.46) by sources.redhat.com with SMTP; 24 Feb 2004 16:47:15 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by coyote.egenera.com (Postfix) with ESMTP id 5DADCA0530 for ; Tue, 24 Feb 2004 11:33:21 -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 22760-10 for ; Tue, 24 Feb 2004 11:33:17 -0500 (EST) Received: from hasufel.egenera.com (southeast.egenera.com [63.160.166.4]) by coyote.egenera.com (Postfix) with ESMTP id C9262A0526 for ; Tue, 24 Feb 2004 11:33:17 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by hasufel.egenera.com (8.11.6/8.11.6) with ESMTP id i1OGgTZ02958 for ; Tue, 24 Feb 2004 11:42:29 -0500 Subject: make execute_control_command conform to docs From: David Allan To: GDB patches Content-Type: multipart/mixed; boundary="=-NPi43tPdsPdyFViIADLB" Organization: Message-Id: <1077640948.1311.61.camel@hasufel.egenera.com> Mime-Version: 1.0 Date: Tue, 24 Feb 2004 16:47:00 -0000 X-Virus-Scanned: by amavisd-new at egenera.com X-SW-Source: 2004-02/txt/msg00684.txt.bz2 --=-NPi43tPdsPdyFViIADLB Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 1275 I've filed PR cli/1566 on this issue. Also, I'm in the process of doing the copyright assignment, but haven't yet completed it. From lurking on the list, it seems like two line patches aren't significant enough to be a problem. (I'm hoping.) The attached patch makes two one-line changes to execute_control_command in cli/cli-script.c to make it conform to the GDB internals documentation section 13.1 on safely using cleanups. Without the patch, execute_control_command depends on the caller having done the right thing by putting something on the cleanup_chain. If execute_control_command is called when cleanup_chain is null, the cleanups execute_control_command puts on the chain are not removed, and undefined behavior results. The patch makes execute_control_command safe by initializing old_chain with a call to make_cleanup with a null_cleanup and always calling do_cleanups before returning if anything other than the null_cleanup has been put on the chain. If the null_cleanup is the only thing put on the chain, it could get left on it at return, but, as I read the code, that's harmless. The other possiblity would be to call do_cleanups at every point we could return, but that seemed like more changes than were necessary to fix the problem. Dave --=-NPi43tPdsPdyFViIADLB Content-Disposition: attachment; filename=execute_control_command.diff Content-Type: text/plain; name=execute_control_command.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-length: 679 Index: cli-script.c =================================================================== RCS file: /cvs/src/src/gdb/cli/cli-script.c,v retrieving revision 1.21 diff -u -r1.21 cli-script.c --- cli-script.c 22 Dec 2003 03:43:19 -0000 1.21 +++ cli-script.c 24 Feb 2004 15:55:06 -0000 @@ -294,7 +294,7 @@ { struct expression *expr; struct command_line *current; - struct cleanup *old_chain = 0; + struct cleanup *old_chain = make_cleanup (null_cleanup, 0); struct value *val; struct value *val_mark; int loop; @@ -427,8 +427,7 @@ return invalid_control; } - if (old_chain) - do_cleanups (old_chain); + do_cleanups (old_chain); return ret; } --=-NPi43tPdsPdyFViIADLB--