[Top][All Lists]

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

Re: Executing shell code on the signal stack, or why is this is a bad id

From: Chet Ramey
Subject: Re: Executing shell code on the signal stack, or why is this is a bad idea
Date: Thu, 06 Jun 2013 11:28:30 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6

On 6/6/13 5:31 AM, Lionel Cons wrote:
> On 6 June 2013 11:29, Lionel Cons <address@hidden> wrote:
>> Forwarding an interesting posting from Roland Mainz who did an
>> investigation why signal trap processing in ksh93, bash and dash is
>> currently not reliable.
>> Lionel
> PS: malloc() from AT&T libast, used by ksh93, is async signal safe.
> Unless bash's sh_malloc() has a similar functionality you'll need a
> different solution, such as using signalfd()

The internal bash malloc (lib/malloc/malloc.c) blocks signals, but it's
easy to compile bash without it, and many malloc implementations (e.g.,
the Linux libc malloc) do not do signal manipulation.

I did a lot of work between bash-4.2 and bash-4.3, currently in alpha
testing, to move any execution of non-signal-safe functions and code out
of signal handlers.

``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]