[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
Re: [Bug-readline] [readline patch, gdb-7.3?] Avoid free from a signal handler [Re: [PATCH] Make interrupting tab-completion safe.]
Wed, 6 Jul 2011 18:44:00 +0200
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
Even if no existing system ever crashes the code is still wrong because it
The following table defines a set of functions that shall be either
reentrant or non-interruptible by signals and shall be
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.
Sure it then has to depend on the application which should properly return to
readline callers immediately if it sees any EINTR.