Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #14071 > unrolled thread

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

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] A terminating signal has to complete a bash process Chet Ramey <chet.ramey@case.edu> - 2018-05-01 14:15 -0400

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

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    chet@case.edu    http://tiswww.cwru.edu/~chet/

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web