From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1373 invoked from network); 30 May 2022 11:17:21 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 30 May 2022 11:17:21 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1653909441; b=rcqO9gsb0GTJSveBBpltpwuZ3nv8f7MsVznLNCMv6d/eCNhYhOSZPAg+azsyzR/tFROXrW2RfJ f3/UvSbb4liMmLsw2fFDUJRITYTAxHlo8eiYAK4GA+wd8W7NuH/hUL3rcqBuV6fCCvUECuZChZ WvRNEBIQjfPP9cAB8Dev+kQedAhWCwD1xImX+1rk+uqD0/wrlQN6P6yRq+Gwv/MneRPPqkJKyb AJAArwJvk2yeS1c0SBJiMQJrjqiFMBZufZWMYp/chZxdCHLpxPtjyEKuu/wlEWS3InaMLezGmk xsVEAP8D83adPRkIk6XluxlXDh14Mkadfwwq2fu2GjUcUg==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (snd00003-bg.im.kddi.ne.jp) smtp.remote-ip=27.86.113.3; dmarc=none header.from=kba.biglobe.ne.jp; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1653909441; bh=rrUxPQguRZgZO5YO/ZLRqHl9aRo7HBGRt1lNpkJfjvE=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Message-ID:In-Reply-To:To:References:Date:Subject: MIME-Version:Content-Transfer-Encoding:Content-Type:From:DKIM-Signature; b=f2VBNiwEdFlvsUp2JBM/be0CY8WQNM/chfJ9/GNLj/xrm9NNaKhd6mf1ZKFtZ8T0Ecx+Cy9pQI wLPcze4ZoWUEsg5oAGLxL0tUncMCfGdi3zZusJ+z/iidfWirZeCK2flex9BQTZrE2T7e5ZZIZA fRqQCDMtQ5LlREP6HXyPLtnwgbpWAINDgFgdE/GeN5pwwWSS5tZiDd3dZvY+Y/fF5VpJ61dIbG Nk6LAGot7ciSN5yNTAil+cSf1IDaYBGAVVHgnoY+qEdPPi5Fj4t3E8mInBaIsTHH6cGxgXR1NG 2ptHRx96y0r4Zo2uMY4YJJFqYt9gTd+MHsUbbv2s3dCILQ==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Message-Id:In-Reply-To:To:References: Date:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:From: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=PtkYwOtm9FeX4pNMBoiG6CR3ttYUJNSObkYaCSEYhzk=; b=ew18It1FS02BxM/9OLax7zaDLa zIN9s+kd07Wa1ZWN490I6AiIgFIHPLECX25Fg7xTKK2vkcbu0XFQFIBfxX11y0PYDV3zh+/VETdoh fufv+66+DfE+9WtfCC7pUlSamZykDimROvPdklVkebjv+u1T3nc8eoSVbnLk0dUBv3PwyJqRPklHR xmMvj1d9Hjg38lITBTYAYFUb2wGNRp/lVE1C3CNnQAXcgdgwXWZ+mQHwIPVyc8oNTUKYVDmkR+DAP LGBo58UTUGl+aWdYttDYcZ3DxZ6d0xbVVlJuuX63gxCwdu65jq8hexwBY9P7HdQWAzL+snrrZviJp Z/onECLw==; Received: from authenticated user by zero.zsh.org with local id 1nvdOj-000I0O-6b; Mon, 30 May 2022 11:17:21 +0000 Authentication-Results: zsh.org; iprev=pass (snd00003-bg.im.kddi.ne.jp) smtp.remote-ip=27.86.113.3; dmarc=none header.from=kba.biglobe.ne.jp; arc=none Received: from snd00003-bg.im.kddi.ne.jp ([27.86.113.3]:52801 helo=dfmta0004.biglobe.ne.jp) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1nvdO9-000Heo-Ap; Mon, 30 May 2022 11:16:47 +0000 Received: from mail.biglobe.ne.jp by omta0004.biglobe.ne.jp with ESMTP id <20220530111639613.UNHR.90319.mail.biglobe.ne.jp@biglobe.ne.jp> for ; Mon, 30 May 2022 20:16:39 +0900 From: Jun T Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: zargs with -P intermittently failing in zsh 5.9 and macOS Date: Mon, 30 May 2022 20:16:39 +0900 References: <9162a41e493cabeb0c8fb7c770f6b35035a0be0e@hey.com> <8CB92976-5B21-4239-844E-93C88EC734F5@kba.biglobe.ne.jp> <957FB7CE-B2AE-4C22-9CC5-0883B2FAB62D@kba.biglobe.ne.jp> <758F3522-3613-435C-B2F6-3FC62220933B@kba.biglobe.ne.jp> To: zsh-workers@zsh.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.21) X-Biglobe-Sender: takimoto-j@kba.biglobe.ne.jp X-Seq: 50306 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: This post is rather long, and divided into (1)-(5). (1) > 2022/05/30 5:07, Bart Schaefer wrote: >=20 > Irrelevant to the patch, but on the original issue, I keep looking at > this and wondering how we got an exit code of 19 rather than 19+128 > which would have immediately pointed to SIGCONT. Is this a difference > in the way MacOS defines WEXITSTATUS(), or what? On both macOS and Linux, WEXITSTATUS(status) is equivalent to (((status) & 0xff00) >> 8). This is so either WIFEXITED() is true or = not. But on both OSes, wait(2) man page says that WEXITSTATUS() can be used = only when WIFEXITED() is true. When WIFCONTINUED() is true we should have = used "0200 | SIGCONT". (2) Why zrags has the problem only on macOS The reason seems to be in the way SIGCONT is handled (in the kernel?). On macOS, if the parent zsh sends SIGCONT to a background child and calls wait3(), then wait3() returns with WIFCONTINUED even if the child has not been stopped. This is _quite_ strange, and does not happen on Linux. You may try the following C program: #include #include #include #include #include int main() { pid_t pid =3D fork(); if (pid < 0) return -1; if (pid > 0) { pid_t wpid; int state; struct rusage ru; kill(pid, SIGCONT); wpid =3D wait3(&state, WUNTRACED|WCONTINUED, &ru); printf("wait3: %d 0x%04x\n", wpid, state); kill(pid, SIGKILL); } else { sleep(1); } return 0; } On Linux, it outputs, after waiting for 1 second: wait3: 76819 0x0000 but on macOS it immediately outputs: wait3: 84313 0x137f For status=3D0x137f, WIFCONTINUED(status)=3Dtrue, and WEXITSTATUS(x)=3D0x13=3D19 (3) zsh on Linux also has a problem On Linux (and macOS), zsh (without the patch) has the following problem: % sleep 20 & [1] 78570 % kill -STOP 78570 [1] + 78570 suspended (signal) sleep 20 % kill -CONT 78570 % (after 20 seconds) [1] + 78570 done sleep 20 % wait 78570 % echo $? 147 # should be 0 147 =3D 0200 + SIGSTOP(=3D19) (on macOS we get 145) (4) Another minor problem In the current zsh (without the patch), when WIFSTOPPED()=3Dtrue, addbgstatus() records "0200 | WEXITSTATUS(status)" in bgstatus_list. But wait(2) manpage says WEXITSTATUS() can be used only if WIFEXITED() is true, and when WIFSTOPPED() is true WSTOPSIG() should be used. On both Linux and macOS (and probably on other OSes) WSTOPSIG() is equivalent to WEXITSTATUS(), so there was no observable problem. grep WEXITSTATUS in the zsh source tree shows that there are two more uses of WEXITSTATUS() (in jobs.c) which are better replaced by WSTOPSIG(), as in the patch shown in (5) below. And: >> + /* See if an entry already exists for the pid */ >=20 > Would it be worthwhile to put that entire thing in #ifdef DEBUG ? Slow down is negligible, as you write, but I think chances are _very_ low that addbgusage() is called more than once. So I enclosed it by #ifdef DEBUG as you suggested. Also added a test for the problem (3) above. (5) Revised patch with test diff --git a/Src/jobs.c b/Src/jobs.c index a91ef787f..80893cebf 100644 --- a/Src/jobs.c +++ b/Src/jobs.c @@ -414,7 +414,7 @@ storepipestats(Job jn, int inforeground, int = fixlastval) jpipestats[i] =3D (WIFSIGNALED(p->status) ? 0200 | WTERMSIG(p->status) : (WIFSTOPPED(p->status) ? - 0200 | WEXITSTATUS(p->status) : + 0200 | WSTOPSIG(p->status) : WEXITSTATUS(p->status))); if (jpipestats[i]) pipefail =3D jpipestats[i]; @@ -471,7 +471,7 @@ update_job(Job jn) val =3D (WIFSIGNALED(pn->status) ? 0200 | WTERMSIG(pn->status) : (WIFSTOPPED(pn->status) ? - 0200 | WEXITSTATUS(pn->status) : + 0200 | WSTOPSIG(pn->status) : WEXITSTATUS(pn->status))); signalled =3D WIFSIGNALED(pn->status); } @@ -2221,6 +2221,7 @@ addbgstatus(pid_t pid, int status) { static long child_max; Bgstatus bgstatus_entry; + LinkNode node; =20 if (!child_max) { #ifdef _SC_CHILD_MAX @@ -2244,6 +2245,21 @@ addbgstatus(pid_t pid, int status) if (!bgstatus_list) return; } +#ifdef DEBUG + /* See if an entry already exists for the pid */ + for (node =3D firstnode(bgstatus_list); node; incnode(node)) { + bgstatus_entry =3D (Bgstatus)getdata(node); + if (bgstatus_entry->pid =3D=3D pid) { + /* In theory this should not happen because addbgstatus() is + * called only once when the process exits or gets killed. = */ + dputs("addbgstatus called again: status %d -> %d", + bgstatus_entry->status, status); + bgstatus_entry->status =3D status; + return; + } + } +#endif + /* Add an entry for the pid */ if (bgstatus_count =3D=3D child_max) { /* Overflow. List is in order, remove first */ rembgstatus(firstnode(bgstatus_list)); diff --git a/Src/signals.c b/Src/signals.c index 5c787e2a8..a61368554 100644 --- a/Src/signals.c +++ b/Src/signals.c @@ -576,12 +576,10 @@ wait_for_processes(void) */ if (jn && !(jn->stat & (STAT_CURSH|STAT_BUILTIN)) && jn - jobtab !=3D thisjob) { - int val =3D (WIFSIGNALED(status) ? - 0200 | WTERMSIG(status) : - (WIFSTOPPED(status) ? - 0200 | WEXITSTATUS(status) : - WEXITSTATUS(status))); - addbgstatus(pid, val); + if (WIFEXITED(status)) + addbgstatus(pid, WEXITSTATUS(status)); + else if (WIFSIGNALED(status)) + addbgstatus(pid, 0200 | WTERMSIG(status)); } =20 unqueue_signals(); diff --git a/Test/A05execution.ztst b/Test/A05execution.ztst index d95ee363c..b257ddf2c 100644 --- a/Test/A05execution.ztst +++ b/Test/A05execution.ztst @@ -396,6 +396,13 @@ F:anonymous function, and a descriptor leak when = backgrounding a pipeline # TBD: the 0 above is believed to be bogus and should also be turned # into 127 when the ccorresponding bug is fixed in the main shell. =20 + sleep 1 & pid=3D$! + kill -STOP $pid + sleep 1 + kill -CONT $pid + wait $pid +0:wait for stopped and continued process + # Without the outer subshell, the test harness reports the pre-46060 = behaviour # as "skipped" rather than "failed". (( exit 130 ) | { sleep 1; echo hello })