Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14045
| From | Chet Ramey <chet.ramey@case.edu> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: [BUG] RETURN trap with -o functrace: infinite recursion on 'eval return' |
| Date | 2018-04-13 21:49 -0400 |
| Organization | ITS, Case Western Reserve University |
| Message-ID | <mailman.12340.1523670609.27995.bug-bash@gnu.org> (permalink) |
| References | <34b02ae0-06b5-0559-a085-efeccc468732@inlv.org> |
On 4/10/18 5:56 AM, Martijn Dekker wrote:
> $ bash -o functrace -c 'fn() { eval "return"; }; trap "fn" RETURN; fn'
>
> Result: segfault due to infinite recursion.
Thanks for the report; I'll fix this.
__________
>
> Even apart from this bug with 'eval return', the effect of '-o functrace'
> is a bit strange:
>
> $ bash -o functrace -c 'fn() { printf foo; fn2; };
> fn2() { printf bar; fn3; };
> fn3() { printf baz\\n; };
> trap fn RETURN; fn'
> foobarbaz
> foobarbaz
> foobarbaz
> foobarbaz
>
> (I'd expect one 'foobarbaz', not four)
>
> 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. If the RETURN trap is inherited
by functions, and traps are recursive, wouldn't the bash behavior be the
logical thing to do? (Yes, I know there are problems with recursive signal
handler invocations in bash-4.4.)
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/
Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread
Re: [BUG] RETURN trap with -o functrace: infinite recursion on 'eval return' Chet Ramey <chet.ramey@case.edu> - 2018-04-13 21:49 -0400
csiph-web