Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14071
| 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
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