[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-readline] [readline patch, gdb-7.3?] Avoid free from a signal h

From: Chet Ramey
Subject: Re: [Bug-readline] [readline patch, gdb-7.3?] Avoid free from a signal handler [Re: [PATCH] Make interrupting tab-completion safe.]
Date: Thu, 07 Jul 2011 08:10:08 -0400
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20110616 Thunderbird/3.1.11

On 7/6/11 12:44 PM, Jan Kratochvil wrote:
> On Wed, 06 Jul 2011 17:58:26 +0200, Chet Ramey wrote:
>> As I said, I'm willing to remove these references and see what happens.  
>> Since
>> you have a way to readily reproduce the problem, I was hoping you'd do it
>> and let me know what you found.
> I do not think any testing matters here.  This is a difficult to reproduce
> race + memory corruption.  While a crash proves it is wrong no crash does not
> prove anything.

The impression I got from your earlier message is that is is very easy
to reproduce using a GDB .exp file:

"Used this GDB .exp file, reproducible in several seconds"

All I am asking you do to is to check whether you can reproduce it using
the same .exp file after removing references to _rl_interrupt_immediately
in complete.c.

> Even if no existing system ever crashes the code is still wrong because it
> violates POSIX:
> http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html
>       The following table defines a set of functions that shall be either
>       reentrant or non-interruptible by signals and shall be 
> async-signal-safe.
> Static code analysis is the only valid verification.  Currently the signal
> code calls free() which is not listed in the safe syscalls list above,
> therefore the code is not correct.
> 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

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]