cc: [email protected] [email protected]
Subject: Re: Signal trap loop behaviour...
--------
> While doing some tests with ast-ksh.2013-02-22 I noticed an odd
> behaviour with signal traps:
> The following example should (in theory) run in an endless loop... but
> ast-ksh.2013-02-22 prints only one iteration and then quits:
> -- snip --
> $ ~/bin/ksh -c 'trap "echo blabla ; kill -RTMIN $$ ; true" RTMIN ;
> kill -RTMIN $$ ; true ; echo done'
> blabla
> done
> -- snip --
>
> Why does that happen ? Both bash and dash print multiple lines with
> "blabla" ... either until the stack is exhausted (leading to a
> SIGSEGV/SIGBUS) or an internal limit is eached... and AFAIK ksh93
> should allow endless loops, too... but without crashing or having
> issues with internal limits.
>
> Would it be standard-conforming to change the behaviour to save a
> signal (and siginfo data) while a trap for the same signal number and
> execute the trap again for each entry in that list ? That would allow
> that traps are executed as expected but without recursing deeper and
> deeper into the stack until it is exhausted (alternatively... if this
> is not conforming behaviour... it may be nice to offer an option for
> this signal-deferring-until-trap-is-done behaviour) ...
>
> ----
>
> Bye,
> Roland
>
The way I read the standard, there is no reason for a shell to run
out of stack space.
In section 2.11, Signals and Error Handling, paragraph 2 states,
"When a signal for which a trap has been set is received, while the
shell is waiting for a foreground command, the trape associated with that
signal shall not be executed until after the foreground comand
has completed."
In your example, the foreground command is
kill -RTMIN $$
and this command must complete. Similarily, the trap command must be
complete before 'kill -RTMIN $$' from within the trap can begin
to execute so that stack would not have grown.
In ksh, I disable the signal corresponding to the signal I am
processing (the way C does) when I run a trap on the signal so it
only executes once.
This avoids an infinite loop.
David Korn
[email protected]
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
