[Top][All Lists]

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

Re: [bash-bug] no local bash_history created or written to if existing (

From: Eric Blake
Subject: Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history
Date: Tue, 08 Mar 2011 11:32:54 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7

On 03/08/2011 11:00 AM, Andreas Schwab wrote:
> "Dr. Werner Fink" <address@hidden> writes:
>> On Tue, Mar 08, 2011 at 12:02:53PM -0500, Chet Ramey wrote:
>>>> Does this mean that the attached patch could also not work
>>>> on some systems? Or does this interfere with the readline
>>>> library?
>>> Since longjmp is not on the list of functions that is safe to call
>>> from a signal handler, yes, that's what it means.  OTOH, this shows
>>> promise as a solution.
>> OK, that means only for systems with HAVE_POSIX_SIGSETJMP
>> defined.  At least this provides a (local) solution here
> sigsetjmp is the same as setjmp.  Both will lead to deadlocks.

sigsetjmp is safe to call from a signal handler _if_ you are in the
handler because of a synchronous signal (such as one generated
internally by raise(), and not generated externally and asynchronously
by kill()), or if you can prove that it was not interrupting any other
non-async-signal-safe function (however, blocking all signals around all
calls to non-async-signal-safe functions is very inefficient).  But
deadlock is indeed possible if an asynchronous SIGHUP occurs while the
malloc() lock is held (if you try to malloc() in the cleanup code, but
siglongjmp() left the middle of earlier code that already held the
malloc() lock, then you indeed have deadlock).  Which is why POSIX does
not list siglongjmp() as an async-signal-safe function, because after
siglongjmp(), you are generally only safe to invoke async-signal-safe
functions, which is no better than invoking those same functions
directly within the signal handler itself in the first place.

Really, the only safe way to handle things like SIGHUP cleanup is to
have the signal handler record that an exception occurred, then have the
main processing loop checking that variable frequently enough to do
cleanup in a reasonable time-frame (possibly by using a pipe-to-self if
the main loop is waiting on select()), where the main loop then
re-raises the signal after doing cleanup at a point where all functions
are safe.

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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