From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28060 invoked by alias); 30 Mar 2006 13:05:26 -0000 Received: (qmail 28051 invoked by uid 22791); 30 Mar 2006 13:05:26 -0000 X-Spam-Check-By: sourceware.org Received: from fra-del-02.spheriq.net (HELO fra-del-02.spheriq.net) (195.46.51.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 30 Mar 2006 13:05:24 +0000 Received: from fra-out-01.spheriq.net (fra-out-01.spheriq.net [195.46.51.129]) by fra-del-02.spheriq.net with ESMTP id k2UD5LHx012300 for ; Thu, 30 Mar 2006 13:05:21 GMT Received: from fra-cus-02.spheriq.net (fra-cus-02.spheriq.net [195.46.51.38]) by fra-out-01.spheriq.net with ESMTP id k2UD5J05025531 for ; Thu, 30 Mar 2006 13:05:19 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-02.spheriq.net with ESMTP id k2UD5H6O027219 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 30 Mar 2006 13:05:19 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id F24AEDA55 for ; Thu, 30 Mar 2006 13:05:13 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D5AF0473A2 for ; Thu, 30 Mar 2006 13:09:15 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CHK23923 (AUTH stubbsa); Thu, 30 Mar 2006 14:05:12 +0100 (BST) Message-ID: <442BD6F1.8070804@st.com> Date: Thu, 30 Mar 2006 14:29:00 -0000 From: Andrew STUBBS User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: GDB Patches Subject: command_line_input() not re-entrant Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.2.01 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00359.txt.bz2 Hi, I have discovered a problem in the GDB command line reading code. command_line_input() uses a static buffer to hold the current command. This means that it is not properly re-entrant - commands that contain other commands, such as user defined commands, are not handled safely. In practice the only real trouble I have observed is with user defined commands that use $arg0 etc. because these parameters are never copied out of the original string, so are overwritten the next time command_line_input() is invoked. Even then, this is not normally a problem because command_line_input() is not normally needed within a user-defined command - it has already been read. It is only a problem when the user defined command contains a source command. The problem may be reproduced as follows: Create three files: a1 ---8<---------->8----- source a2 abcdef qwerty ---8<---------->8----- a2 ---8<---------->8----- define abcdef echo 1: <<<$arg0>>>\n source a3 echo 2: <<<$arg0>>>\n end ---8<---------->8----- a3 ---8<---------->8----- ################################################################# ---8<---------->8----- Then run the following command: $ gdb -nx -q -x a1 -batch 1: <<>> 2: <<<######>>> Both 1: and 2: should have been the same. As you can see the contents of a3 have overwritten the value of $arg0 in abcdef. For some reason I haven't discovered (and probably boils down to dumb luck) I can't reproduce the problem when entering a1 interactively - I have to source it. I am happy to write the patch to fix this but I am wondering how. There seem to be two possible ways: 1. Make command_line_input() re-entrant. Perhaps drop the static buffer and malloc a new string each time. Free it through a clean-up. 2. Have setup_user_args() copy the data and adjust the clean up to free the copied data. Any preferences or other suggestions? Andrew Stubbs