Re: bugs in trap signal handling

[Chet Ramey]

On 10/10/12 2:53 AM, lanshun zhou wrote:
> Red Hat Enterprise Linux Server release 6.2 (Santiago)
> uname -r:       2.6.32-220.17.1.el6.x86_64
> bash version: bash-4.1.2-9.el6_2.src.rpm  (also tested with bash-4.2
> compiled from source
> with patches bash42-001~bash42-037)
> 
> When interrupt_immediately is set, handler for signals registered by trap
> is called
> immediately after the signal is triggered. But many function calls in
> trap_handler
> are not async-signal-safe, so it's unsafe and could cause bash to enter
> a deadlock.

Thanks for the report.  This has been under discussion for a long time.

There are a couple of issues: how one satisfies users' expections of
responsiveness, and what to do with partially-read input.  The work on
that continues.

Right now, I've been running a slightly modified version of your script
(I changed the echo -n ? to echo ? to avoid stdio buffering issues) for
over an hour on a RHEL5 system without any lockups.  I have ideas about
what to do to reduce the potential deadlock window, but I need a way to
measure the effect of those changes.

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/