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

Groups > gnu.bash.bug > #16508

Re: approach to async-signal safety in bash

Show key headers only | View raw

On 6/30/20 4:28 PM, Godmar Back wrote:
> Hi,
> 
> I'm trying to understand what approach bash takes to async-signal safety in
> its design.

I'm always interested in this kind of analysis, since signal handling
conflicts can be a ripe source of deadlocks -- think glibc and its dozens
of internal locks.

> Looking at the bash 5.0 code, I see some comments in the code about
> strategies to protect the jobs array and other data structures from
> arriving SIGCHLD signals, but I have questions about, for instance, these:
> 
> - printable_job_status uses a 'static' variable "temp". However,
> printable_job_status is called during the execution of the builtin command
> "jobs" and here (I believe at least) without blocking or queuing SIGCHLD.

I don't see how. It either calls list_{all,running,stopped}_jobs, which end
up calling map_over_jobs and blocking SIGCHLD there, or jobs_builtin blocks
SIGCHLD itself before calling list_one_job.

> Therefore, if set -b is set, it could be reentered if a child process exits
> at that time. This could clobber 'temp'.
So this and the next one cover set -b, which by design has to notify
asynchronously, out of the signal handler. Maybe it would be better to run
it only if the shell is reading command input at the time the signal
arrives.

> 
> - If set -b is set, calls to notify_job_status from the SIGCHLD handler may
> invoke printf or fprintf(stderr,), which is also called on builtin paths,
> for instance, when executing just "set" and listing all variables/functions.
> 
> - The SIGALRM handler in eval.c calls printf and fflush(stdout), even
> though SIGALRM doesn't appear to be blocked elsewhere where printf() is
> called.

This is another case that I find unlikely to cause problems, since the code
path this call surrounds doesn't include other calls to printf. The signal
handler is only installed while the shell is reading a command.


-- 
``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

Thread

Re: approach to async-signal safety in bash Chet Ramey <chet.ramey@case.edu> - 2020-07-01 10:58 -0400

csiph-web