From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2662 invoked by alias); 8 Jul 2011 14:26:44 -0000 Received: (qmail 2652 invoked by uid 22791); 8 Jul 2011 14:26:42 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mpv2.tis.cwru.edu (HELO mpv2.tis.cwru.edu) (129.22.105.37) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 Jul 2011 14:26:27 +0000 Received: from mpv6.cwru.edu (mpv6.tis.cwru.edu [129.22.104.221]) by mpv2.tis.cwru.edu (MOS 4.2.3-GA) with ESMTP id BAO82786; Fri, 8 Jul 2011 10:26:25 -0400 Received: from caleb.INS.CWRU.Edu (caleb.INS.CWRU.Edu [129.22.8.211]) by mpv6.cwru.edu (MOS 4.2.3-GA) with ESMTP id AFS71607 (AUTH cpr); Fri, 8 Jul 2011 10:26:22 -0400 Message-ID: <4E17138D.9060701@case.edu> Date: Fri, 08 Jul 2011 16:03:00 -0000 From: Chet Ramey Reply-To: chet.ramey@case.edu User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Jan Kratochvil CC: chet.ramey@case.edu, bug-readline@gnu.org, gdb-patches@sourceware.org, Sterling Augustine Subject: Re: [Bug-readline] [readline patch, gdb-7.3?] Avoid free from a signal handler [Re: [PATCH] Make interrupting tab-completion safe.] References: <20110612121158.GA10611@host1.jankratochvil.net> <20110626222146.GA4410@host1.jankratochvil.net> <4E0B2E83.9030202@case.edu> <20110629203457.GA28353@host1.jankratochvil.net> <4E0C8A5D.7000807@case.edu> <20110706154621.GA17142@host1.jankratochvil.net> <110706155826.AA07325.SM@caleb.INS.CWRU.Edu> <20110706164400.GA31447@host1.jankratochvil.net> <4E15A220.4030404@case.edu> In-Reply-To: <4E15A220.4030404@case.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A020202.4E171392.010C,ss=1,fgs=0, ip=0.0.0.0, so=2010-12-23 16:51:53, dmn=2009-09-10 00:05:08, mode=single engine Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-07/txt/msg00257.txt.bz2 On 7/7/11 8:10 AM, I wrote: >> I do not know if it is possible to code _rl_handle_signal in a way which uses >> only the safe syscalls and only atomic operations on volatile data structures. >> Anyway even if it would be possible I find such code very fragile and >> I believe the signals should be always delayed through _rl_caught_signal. > > Ironically, I changed it to respond immediately to signals when in callback > mode because of a bug you filed from gdb. When readline was reading input > using rl_callback_read_char it did not respond quickly enough to SIGINT, > and gdb didn't catch it. You will have to check and make sure the > conditions have changed enough to make it acceptable to delay signal > handling. It occurs to me that this will not work unless I make changes to readline's callback implementation. Currently readline installs its signal handlers as part of the callback setup (rl_callback_handler_install -> _rl_callback_newline). This results in a situation where readline's signal handlers are active when the application has flow control. I imagine the most likely scenario is that the application (gdb) is in a select() call waiting for input when the signal arrives, readline sets a flag, and the select call either restarts or returns -1/EINTR. Either way, gdb can't do anything about it except guess. The most straightforward solution would be to move the signal setup into rl_callback_read_char, so readline's signal handlers are in place only when readline has control. It's still important that the application call rl_callback_handler_remove to restore the original signal handlers. Once that's done, readline will not have to call signal handlers synchronously when running in callback mode. Thoughts? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/