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 Newsgroups: gnu.bash.bug Subject: Re: [BUG] RETURN trap with -o functrace: infinite recursion on 'eval return' Date: Sun, 15 Apr 2018 22:04:20 -0400 Organization: ITS, Case Western Reserve University Lines: 28 Approved: bug-bash@gnu.org Message-ID: References: <34b02ae0-06b5-0559-a085-efeccc468732@inlv.org> 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: 7bit X-Trace: usenet.stanford.edu 1523844278 23364 208.118.235.17 (16 Apr 2018 02:04:38 GMT) X-Complaints-To: action@cs.stanford.edu Cc: chet.ramey@case.edu To: Martijn Dekker , "bug-bash@gnu.org" 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/di50Gm1l1Na63d3RZ00SeFQos6WEwLUHEB0yp6KXluXLLIZitEJM0aQ2hldCBSYW1l eSA8Y2hldEBjd3J1LmVkdT7CYQQTEQIAIQIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAUCQ+La kQIZAQAKCRC7WGnwZOp0q9rGAJ4sRGLmlF8klZTH75z7jyQScpU6aACeNMahjWIhumt4u96d 9mdMJqlabVnOwE0EQQ6wbxAEAJCukwDigRDPhAuI+lf+6P64lWanIFOXIndqhvU13cDbQ/Wt 5LwPzm2QTvd7F+fcHOgZ8KOFScbDpjJaRqwIybMTcIN0B2pBLX/C10W1aY+cUrXZgXUGVISE MmpaP9v02auToo7XXVEHC+XLO9IU7/xaU98FL69l6/K4xeNSBRM/AAMHA/wNAmRBpcyK0+Vg gZ5esQaIP/LyolAm2qwcmrd3dZi+g24s7yjV0EUwvRP7xHRDQFgkAo6++QbuecU/J90lxrVn QwucZmfz9zgWDkT/MpfB/CNRSKLFjhYq2yHmHWT6vEjw9Ry/hF6Pc0oh1a62USdfaKAiim0n VxxQmPmiRvtCmcJJBBgRAgAJBQJBDrBvAhsMAAoJELtYafBk6nSr43AAn2ZZFQg8Gs/zUzvX Mt7evaFqVTzcAJ0cHtKpP1i/4H4R9+OsYeQdxxWxTQ== User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: Content-Language: en-US X-Junkmail-Status: score=7/90, host=mpv3-2015.case.edu X-Junkmail-PrAS-Raw: score=7/90, refid=2.7.2:2018.4.16.14816:17:7.944, ip=, rules=__HAS_REPLYTO, __HAS_CC_HDR, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __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_CC1, __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, BODY_SIZE_1100_1199, BODYTEXTP_SIZE_3000_LESS, __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, __TO_REAL_NAMES, MULTIPLE_REAL_RCPTS, LEGITIMATE_SIGNS, __SINGLE_URI_TEXT, [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.194 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:14049 On 4/13/18 11:29 PM, Martijn Dekker wrote: > Op 14-04-18 om 03:49 schreef Chet Ramey: >> On 4/10/18 5:56 AM, Martijn Dekker wrote: >>> It seems odd that the RETURN trap would be triggered while a RETURN trap >>> action is still being executed. Might it be better to temporarily >>> deactivate the effect of '-o functrace' while a RETURN trap action is being >>> executed? >> >> Well, trap handlers are recursive, in the sense that you can execute a trap >> on signal X from a signal X trap handler. > > I'm not sure how that would happen. Isn't a signal blocked while executing > its trap handler? No. Since trap handlers are not executed in a signal handler context, there's no reason to block signals while a trap handler is running. Bash doesn't generally allow a trap handler for signal X to run while a trap handler for signal X is executing, but other shells do. This (bash not allowing this trap recursion generally) has been reported as a bug in the past. Chet -- ``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/