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


Groups > gnu.bash.bug > #14071

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

Path csiph.com!weretis.net!feeder6.news.weretis.net!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!bloom-beacon.mit.edu!bloom-beacon.mit.edu!171.64.64.130.MISMATCH!usenet.stanford.edu!not-for-mail
From Chet Ramey <chet.ramey@case.edu>
Newsgroups gnu.bash.bug
Subject Re: [PATCH] A terminating signal has to complete a bash process
Date Tue, 1 May 2018 14:15:17 -0400
Lines 55
Approved bug-bash@gnu.org
Message-ID <mailman.13219.1525198534.27995.bug-bash@gnu.org> (permalink)
References <20180430220520.32312-1-avagin@openvz.org> <e131b7b7-bd73-85b0-c5e4-88b66cab861a@case.edu> <20180501164422.GA7043@outlook.office365.com>
Reply-To chet.ramey@case.edu
NNTP-Posting-Host lists.gnu.org
Mime-Version 1.0
Content-Type text/plain; charset=utf-8
Content-Transfer-Encoding 8bit
X-Trace usenet.stanford.edu 1525198534 25582 208.118.235.17 (1 May 2018 18:15:34 GMT)
X-Complaints-To action@cs.stanford.edu
Cc chet.ramey@case.edu, Andrei Vagin <avagin@openvz.org>, bug-bash@gnu.org
To Andrei Vagin <avagin@virtuozzo.com>
Envelope-to bug-bash@gnu.org
Openpgp preference=signencrypt
Autocrypt addr=chet.ramey@case.edu; prefer-encrypt=mutual; keydata= xsDiBEEOsGwRBACFa0A1oa71HSZLWxAx0svXzhOZNQZOzqHmSuGOG92jIpQpr8DpvgRh40Yp AwdcXb8QG1J5yGAKeevNE1zCFaA725vGSdHUyypHouV0xoWwukYO6qlyyX+2BZU+okBUqoWQ koWxiYaCSfzB2Ln7pmdys1fJhcgBKf3VjWCjd2XJTwCgoFJOwyBFJdugjfwjSoRSwDOIMf0D /iQKqlWhIO1LGpMrGX0il0/x4zj0NAcSwAk7LaPZbN4UPjn5pqGEHBlf1+xDDQCkAoZ/VqES GZragl4VqJfxBr29Ag0UDvNbUbXoxQsARdero1M8GiAIRc50hj7HXFoERwenbNDJL86GPLAQ OTGOCa4W2o29nFfFjQrsrrYHzVtyA/9oyKvTeEMJ7NA3VJdWcmn7gOu0FxEmSNhSoV1T4vP2 1Wf7f5niCCRKQLNyUy0wEApQi4tSysdz+AbgAc0b/bHYVzIf2uO2lIEZQNNt+3g2bmXgloWm W5fsm/di50Gm1l1Na63d3RZ00SeFQos6WEwLUHEB0yp6KXluXLLIZitEJM0gQ2hldCBSYW1l eSA8Y2hldC5yYW1leUBjYXNlLmVkdT7CYQQTEQIAIQIbAwYLCQgHAwIDFQIDAxYCAQIeAQIX gAUCRX3FIgIZAQAKCRC7WGnwZOp0q069AKCNDRn+zzN/AHbaynls/Lvq1kH/RQCgkLvF8bDs maUHSxSIPqzlGuKWDxbOwE0EQQ6wbxAEAJCukwDigRDPhAuI+lf+6P64lWanIFOXIndqhvU1 3cDbQ/Wt5LwPzm2QTvd7F+fcHOgZ8KOFScbDpjJaRqwIybMTcIN0B2pBLX/C10W1aY+cUrXZ gXUGVISEMmpaP9v02auToo7XXVEHC+XLO9IU7/xaU98FL69l6/K4xeNSBRM/AAMHA/wNAmRB pcyK0+VggZ5esQaIP/LyolAm2qwcmrd3dZi+g24s7yjV0EUwvRP7xHRDQFgkAo6++QbuecU/ J90lxrVnQwucZmfz9zgWDkT/MpfB/CNRSKLFjhYq2yHmHWT6vEjw9Ry/hF6Pc0oh1a62USdf aKAiim0nVxxQmPmiRvtCmcJJBBgRAgAJBQJBDrBvAhsMAAoJELtYafBk6nSr43AAn2ZZFQg8 Gs/zUzvXMt7evaFqVTzcAJ0cHtKpP1i/4H4R9+OsYeQdxxWxTQ==
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
In-Reply-To <20180501164422.GA7043@outlook.office365.com>
Content-Language en-US
X-Junkmail-Status score=8/90, host=mpv4-2015.case.edu
X-Junkmail-PrAS-Raw score=8/90, refid=2.7.2:2018.5.1.173616:17:8.317, ip=, rules=__HAS_REPLYTO, __HAS_CC_HDR, __MULTIPLE_RCPTS_CC_X2, __CC_NAME, __CC_NAME_DIFF_FROM_ACC, __PHISH_SPEAR_SUBJ_PREDICATE, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __TO_MALFORMED_2, __TO_NAME, __TO_NAME_DIFF_FROM_ACC, __REFERENCES, __HAS_FROM, FROM_EDU_TLD, __HAS_MSGID, __SANE_MSGID, DATE_TZ_NA, __USER_AGENT, __MOZILLA_USER_AGENT, __MIME_VERSION, __IN_REP_TO, __CT, __CT_TEXT_PLAIN, __CTE, __REPLYTO_SAMEAS_FROM_ADDY, __REPLYTO_SAMEAS_FROM_ACC, __FROM_DOMAIN_IN_ANY_CC2, __REPLYTO_SAMEAS_FROM_DOMAIN, __ANY_URI, __URI_WITH_PATH, __URI_NO_WWW, __CP_URI_IN_BODY, __SUBJ_ALPHA_NEGATE, __URI_IN_BODY, __URI_NOT_IMG, __FORWARDED_MSG, __NO_HTML_TAG_RAW, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_P1, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, IN_REP_TO, MSG_THREAD, __FROM_DOMAIN_IN_RCPT, [TRUNCATED], so=2010-03-03 19:42:08, dmn=2016-08-03-0138
X-detected-operating-system by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy]
X-Received-From 129.22.103.195
X-BeenThere bug-bash@gnu.org
X-Mailman-Version 2.1.21
Precedence list
List-Id Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive <http://lists.gnu.org/archive/html/bug-bash/>
List-Post <mailto:bug-bash@gnu.org>
List-Help <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
Xref csiph.com gnu.bash.bug:14071

Show key headers only | View raw


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/

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread


Thread

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

csiph-web