bug-bash
[Top][All Lists]
Advanced

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

Re: [PATCH] A terminating signal has to complete a bash process


From: Chet Ramey
Subject: Re: [PATCH] A terminating signal has to complete a bash process
Date: Tue, 1 May 2018 14:15:17 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 5/1/18 12:44 PM, Andrei Vagin wrote:
> On Tue, May 01, 2018 at 10:40:18AM -0400, Chet Ramey wrote:
>> On 4/30/18 6:05 PM, Andrei Vagin wrote:
>>> bash sets a handler for all terminating signals, which saves history,
>>> executes traps, sets a default signal handler and re-sends the same
>>> signal to itself. It expects that this signal will kill it.
>>>
>>> Unfortunately it doesn't work in Linux, when a bash script is executed as
>>> an init process in a pid namespaces, because all signals to the init
>>> process, what are sent from the current pid namespace, are ignored.
>>>
>>> man 7 pid_namespaces
>>>   Only signals for which the "init" process has established a signal han‐
>>>   dler can be sent to the "init" process by  other  members  of  the  PID
>>>   namespace.   This restriction applies even to privileged processes, and
>>>   prevents other members of the PID namespace from  accidentally  killing
>>>   the "init" process.
>>>
>>> Chet Ramey suggested to add a call to exit() after the kill(). This
>>> patch adds this call for signals, which do not result in a core dump.
>>> For other signals, a null pointer is dereferenced to get a core file.
>>
>> What's the value of a core dump from a different signal in this case?
> 
> If we get these signals from kernel, it means that we have a bug. 

Usually, yes. But the usefulness of a core dump depends on two things:

1. Whether the core dump contains enough useful information to point to
   a problem. This can be defeated by not compiling the program with
   debugging symbols or by the stack being corrupted enough to obscure
   the bug's origin. I am not sure that a core dump generated by a
   different signal (caused by dereferencing a random area in memory)
   will leave any resultant core file intact enough to be useful.

2. Whether the problem that elicited the core dump can be reproduced. If
   it's not immediately obvious from the core dump, you have to be able
   to reproduce the problem in order to fix it. I'm skeptical that this
   will be the case.

> Modern linux distributions
> automatically detect code dump files, and generates a bug report with
> all required information.

And what does "all required information" entail?

If it's not obvious, I'm trying to determine whether making this change
will add any more value than simply exiting (perhaps with a particular
exit status).

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



reply via email to

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