X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:from:date:message-id:subject:to
	:content-type; q=dns; s=default; b=tucKW7jDSuMBaQxz9SVyVPfcOoZ6I
	nEBg5KxiLjuin77CBQh4B4lhnhzWRaMAd7B7Bs3bNzJijw2lbzbBIcid+XEtuQW/
	3v0XXuF5HpZ4q0YfXQh0tlTWLi9h5fmxHaf8FKzQEzmAGhAQAPIohuU15KcF9bBK
	Egdalqi22h93KA=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:from:date:message-id:subject:to
	:content-type; s=default; bh=Svq1i1AzRxtODAddOay9dEhGfAY=; b=o0O
	HmSfPS43yPhd3kBPlL5Mcva5eputX1XShJGMS+zoD3AQSzGWqaIVcQ/6kfAy2eAz
	XGSwWBKJnZB/0ViZy/AC1Quc+jPvz50Mt1XdXLI6cQUwDRHbD55yGYVjZXjSJwjF
	W2Z/hiWmkhPdbWstyqV2j7axu5jVXIW392Nyo75Y=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=covers, lifetime, acted, subscribed
X-HELO:	mail-wm0-f65.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TNWj4HJ6ztfAxnpirQt0A0PhsfcUGcPbDhHbAkddDWw=; b=NgH+KuI1nV7MULSqkhtZ+y2AikP03eOh9HnFlDLgcMT/ZarsAdn8Evsdc13sbiHg5N 3Oc6cciofReYP26ri0BAyKfY2HHJtC9XFfO6jF3TniRvxZwsPYwQAnC8PcUR2/BtRRsW DihchsBXfyhTxUqHqPb9arsHeE5n2HSLWlE9poAKWjwdt8YPf3LtV3oIzJV9ZLhPczJx 4zxetmDcgOQhROeW/JgCWnAsTFctHnS54r4wJYK1IsuoEgrM11IZ2eBZfHdE+H87PuCH mu0KAG5Bq7bmlEpUztbWhQLbTCoge5aCK5bP+sCth9tf8sclggJUwEXw7MMDGV9az/Ta Tz2Q==
X-Gm-Message-State:	AEkoous4ml51hRPl7Vdw6vMprKp1XWQEszpfUWpOV+tm3RWDgvzKvduoqLWwECFAD52EIfvQfhRla7LYsRA31A==
X-Received:	by 10.25.219.210 with SMTP id t79mr1366286lfi.110.1470909100450; Thu, 11 Aug 2016 02:51:40 -0700 (PDT)
MIME-Version:	1.0
From:	Erik Bray <erik DOT m DOT bray AT gmail DOT com>
Date:	Thu, 11 Aug 2016 11:51:39 +0200
Message-ID:	<CAOTD34Yv+namnsv+QNL2F-_c+W1-3ZdxZsgPQP8nxBEPNndcgw@mail.gmail.com>
Subject:	2.5.1: kill(pid, sig) before waitpid() returns -1 for sig != 0
To:	cygwin AT cygwin DOT com

Hi all,

This is a followup to a report back in 2011 about essentially the same issue:

https://cygwin.com/ml/cygwin/2011-04/msg00031.html

The same test program in that report demonstrates the issue, but with
kill sending any non-zero signal.  To reiterate, the problem here is
POSIX compliance with respect to sending signals to zombie processes:

> Existing implementations vary on the result of a kill() with pid indicating an inactive process (a
> terminated process that has not been waited for by its parent). Some indicate success on such a
> call (subject to permission checking), while others give an error of [ESRCH]. Since the definition
> of process lifetime in this volume of POSIX.1-2008 covers inactive processes, the [ESRCH] error
> as described is inappropriate in this case. In particular, this means that an application cannot
> have a parent process check for termination of a particular child with kill(). (Usually this is done
> with the null signal; this can be done reliably with waitpid().)

In response to the originally issue, this was fixed *specifically* for
the case of kill(pid, 0).  But my reading of the above is that kill()
should return 0 in this case regardless of the signal (modulo
permissions, etc.).  On Linux, for example, when calling kill with pid
of a zombie process the kernel will happily deliver the signal to the
relevant task_struct; it will just never be acted on since the task
will never run again.

The below (untested) patch demonstrates the change I'm suggesting,
though I don't know what other code, if any, might be involved in
this.

Please CC me on any replies since I'm not subscribed to the list.

Thanks,
Erik

diff --git a/winsup/cygwin/signal.cc b/winsup/cygwin/signal.cc
index ff101e3..d819e77 100644
--- a/winsup/cygwin/signal.cc
+++ b/winsup/cygwin/signal.cc
@@ -260,7 +260,7 @@ _pinfo::kill (siginfo_t& si)
        }
       this_pid = pid;
     }
-  else if (si.si_signo == 0 && this && process_state == PID_EXITED)
+  else if (this && process_state == PID_EXITED)
     {
       this_process_state = process_state;
       this_pid = pid;

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -