Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Chet Ramey <chet.ramey@case.edu>
Newsgroups: gnu.bash.bug
Subject: Re: approach to async-signal safety in bash
Date: Wed, 1 Jul 2020 10:58:02 -0400
Organization: ITS, Case Western Reserve University
Lines: 48
Approved: bug-bash@gnu.org
Message-ID: <mailman.764.1593615491.2574.bug-bash@gnu.org>
References: <pn9hipci.dag@gnui.org> <CAB4+JYLs7vO-9dOb9inSRF0QC7d67U9RJnduk3oWy+MiaFUOug@mail.gmail.com> <4e5be040-0d4c-6ccb-efad-5a33352681d3@case.edu>
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
Cc: chet.ramey@case.edu
To: Godmar Back <godmar@gmail.com>, bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Autocrypt: addr=chet.ramey@case.edu; prefer-encrypt=mutual; keydata= mQGiBEEOsGwRBACFa0A1oa71HSZLWxAx0svXzhOZNQZOzqHmSuGOG92jIpQpr8DpvgRh40Yp AwdcXb8QG1J5yGAKeevNE1zCFaA725vGSdHUyypHouV0xoWwukYO6qlyyX+2BZU+okBUqoWQ koWxiYaCSfzB2Ln7pmdys1fJhcgBKf3VjWCjd2XJTwCgoFJOwyBFJdugjfwjSoRSwDOIMf0D /iQKqlWhIO1LGpMrGX0il0/x4zj0NAcSwAk7LaPZbN4UPjn5pqGEHBlf1+xDDQCkAoZ/VqES GZragl4VqJfxBr29Ag0UDvNbUbXoxQsARdero1M8GiAIRc50hj7HXFoERwenbNDJL86GPLAQ OTGOCa4W2o29nFfFjQrsrrYHzVtyA/9oyKvTeEMJ7NA3VJdWcmn7gOu0FxEmSNhSoV1T4vP2 1Wf7f5niCCRKQLNyUy0wEApQi4tSysdz+AbgAc0b/bHYVzIf2uO2lIEZQNNt+3g2bmXgloWm W5fsm/di50Gm1l1Na63d3RZ00SeFQos6WEwLUHEB0yp6KXluXLLIZitEJLQwQ2hldCBSYW1l eSAoQ2FzZSBzdGFuZGFyZCkgPGNoZXQucmFtZXlAY2FzZS5lZHU+iF8EExECAB8FAkPi19EC GwMHCwkIBwMCAQMVAgMDFgIBAh4BAheAAAoJELtYafBk6nSrelkAn31Gsuib7GcCZHbv5L5t VKYR9LklAJ4hzUHKA49Z0QXR+qCb80osIcmPSbkBDQRBDrBvEAQAkK6TAOKBEM+EC4j6V/7o /riVZqcgU5cid2qG9TXdwNtD9a3kvA/ObZBO93sX59wc6Bnwo4VJxsOmMlpGrAjJsxNwg3QH akEtf8LXRbVpj5xStdmBdQZUhIQyalo/2/TZq5OijtddUQcL5cs70hTv/FpT3wUvr2Xr8rjF 41IFEz8AAwcD/A0CZEGlzIrT5WCBnl6xBog/8vKiUCbarByat3d1mL6DbizvKNXQRTC9E/vE dENAWCQCjr75Bu55xT8n3SXGtWdDC5xmZ/P3OBYORP8yl8H8I1FIosWOFirbIeYdZPq8SPD1 HL+EXo9zSiHVrrZRJ19ooCKKbSdXHFCY+aJG+0KZiEkEGBECAAkFAkEOsG8CGwwACgkQu1hp 8GTqdKvjcACfZlkVCDwaz/NTO9cy3t69oWpVPNwAnRwe0qk/WL/gfhH346xh5B3HFbFN
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
In-Reply-To: <CAB4+JYLs7vO-9dOb9inSRF0QC7d67U9RJnduk3oWy+MiaFUOug@mail.gmail.com>
Content-Language: en-US
Received-SPF: pass client-ip=129.22.103.226; envelope-from=chet.ramey@case.edu; helo=mpv1-2015.case.edu
X-Spam_score_int: -43
X-Spam_score: -4.4
X-Spam_bar: ----
X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN
X-Spam_action: no action
X-BeenThere: bug-bash@gnu.org
X-Mailman-Version: 2.1.23
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: <https://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>
X-Mailman-Original-Message-ID: <4e5be040-0d4c-6ccb-efad-5a33352681d3@case.edu>
X-Mailman-Original-References: <pn9hipci.dag@gnui.org> <CAB4+JYLs7vO-9dOb9inSRF0QC7d67U9RJnduk3oWy+MiaFUOug@mail.gmail.com>
Xref: csiph.com gnu.bash.bug:16508

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/