From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Brown Newsgroups: gmane.emacs.bugs Subject: bug#14569: 24.3.50; bootstrap fails on Cygwin Date: Sun, 16 Jun 2013 13:51:33 -0400 Message-ID: <51BDFB25.8080101__17975.6633508534$1371405194$gmane$org@cornell.edu> References: <51BC720D.7080504@alice.it> <51BDB979.3040508@cornell.edu> <20130616150141.GB3622@ednor.casa.cgf.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1371405187 27994 80.91.229.3 (16 Jun 2013 17:53:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Jun 2013 17:53:07 +0000 (UTC) Cc: 14569@debbugs.gnu.org To: cygwin@cygwin.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jun 16 19:53:08 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UoH8V-0006Fk-UP for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Jun 2013 19:53:08 +0200 Original-Received: from localhost ([::1]:58431 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoH8V-00039x-Kb for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Jun 2013 13:53:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoH8R-00039r-MN for bug-gnu-emacs@gnu.org; Sun, 16 Jun 2013 13:53:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UoH8Q-0000pV-EC for bug-gnu-emacs@gnu.org; Sun, 16 Jun 2013 13:53:03 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54457) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoH8Q-0000pR-AP for bug-gnu-emacs@gnu.org; Sun, 16 Jun 2013 13:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1UoH8P-0000lh-LT for bug-gnu-emacs@gnu.org; Sun, 16 Jun 2013 13:53:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ken Brown Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 16 Jun 2013 17:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14569 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14569-submit@debbugs.gnu.org id=B14569.13714051392901 (code B ref 14569); Sun, 16 Jun 2013 17:53:01 +0000 Original-Received: (at 14569) by debbugs.gnu.org; 16 Jun 2013 17:52:19 +0000 Original-Received: from localhost ([127.0.0.1]:48773 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UoH7i-0000kh-Ei for submit@debbugs.gnu.org; Sun, 16 Jun 2013 13:52:18 -0400 Original-Received: from limestone4.mail.cornell.edu ([128.253.83.164]:57508) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UoH7f-0000kP-3t for 14569@debbugs.gnu.org; Sun, 16 Jun 2013 13:52:16 -0400 X-CornellRouted: This message has been Routed already. Original-Received: from authusersmtp.mail.cornell.edu ([10.16.197.8]) by limestone4.mail.cornell.edu (8.14.4/8.14.4) with ESMTP id r5GHpv8B001610; Sun, 16 Jun 2013 13:51:58 -0400 (EDT) Original-Received: from [192.168.1.6] (cpe-67-249-194-47.twcny.res.rr.com [67.249.194.47]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id r5GHq4U1031385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Jun 2013 13:52:05 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 In-Reply-To: <20130616150141.GB3622@ednor.casa.cgf.cx> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:75224 Archived-At: On 6/16/2013 11:01 AM, Christopher Faylor wrote: > On Sun, Jun 16, 2013 at 09:11:21AM -0400, Ken Brown wrote: >> [Adding the bug address back to the CC so that this gets archived.] >> >> On 6/15/2013 9:54 AM, Angelo Graziosi wrote: >>> Christopher Faylor wrote >>>>> On 06/14/2013 11:03 AM, Christopher Faylor wrote: >>>>>> You pointed to an archived mail messages which implies that was fixed >>>>>> more than a year ago. What makes you think it is still a problem? >>>>> >>>>> The message I pointed to >>>>> says this: >>>>> >>>>>> Testcase signal/kill: Signals may or may not reach the correct thread >>>>>> with 1.7.12-1 and newer. >>>>> >>>>> Confirmed. I think the reason is that we only have a single event to >>>>> signal that a POSIX signal arrived instead of a per-thread event, but >>>>> I'm not sure. This is cgf's domain so I leave it at that for now. >>>>> >>>>> I interpreted this to mean "the existence of the bug is confirmed, >>>>> here's why the bug occurs, and I'll let cgf deal with it". I didn't >>>>> see any followup message where cgf (is that you?) dealt with it. My >>>>> apologies if I misinterpreted the email. >>>> >>>> Oops. I didn't read Corinna's message as thoroughly as I should have. >>>> Sorry. >>>> >>>> That particular issue was supposed to have been fixed in Cygwin 1.7.17, >>>> released in October 2012. >>> >>> Out of curiosity, I tried the test cases I found in that thread, more >>> precisely here: >>> >>> http://cygwin.com/ml/cygwin/2012-05/msg00434.html >>> >>> >>> and the results are: >>> >>> $ gcc otto_test1.c -o otto_test1 >>> $ ./otto_test1 >>> Testing deferred pthread_cancel() >>> >>> Thread 0 starting (0x200102c0) >>> Thread 1 starting (0x20010360) >>> Thread 2 starting (0x20010400) >>> >>> Cancelling thread 2 (0x20010400) >>> Thread 2 exiting (0x20010400) >>> Cancelling thread 1 (0x20010360) >>> Thread 1 exiting (0x20010360) >>> Cancelling thread 0 (0x200102c0) >>> Thread 0 exiting (0x200102c0) >>> >>> Thread 0 is gone (0x200102c0) >>> Thread 1 is gone (0x20010360) >>> Thread 2 is gone (0x20010400) >>> >>> $ gcc otto_test2.c -o otto_test2 >>> $ ./otto_test2 >>> Testing asynchronous pthread_cancel() >>> >>> Thread 0 starting (0x200102c0) >>> Changing canceltype from 0 to 1 >>> Thread 1 starting (0x20010360) >>> Changing canceltype from 0 to 1 >>> Thread 2 starting (0x20010400) >>> Changing canceltype from 0 to 1 >>> >>> Cancelling thread 2 (0x20010400) >>> Thread 2 exiting (0x20010400) >>> Cancelling thread 1 (0x20010360) >>> Thread 1 exiting (0x20010360) >>> Cancelling thread 0 (0x200102c0) >>> Thread 0 exiting (0x200102c0) >>> >>> Thread 0 is gone (0x200102c0) >>> Thread 1 is gone (0x20010360) >>> Thread 2 is gone (0x20010400) >>> >>> $ gcc otto_test3.c -o otto_test3 >>> $ ./otto_test3 >>> Testing pthread_kill() >>> >>> Thread 0 starting (0x200102c0) >>> Thread 1 starting (0x20010360) >>> Thread 2 starting (0x20010400) >>> >>> Sending SIGUSR1 to thread 2 (0x20010400) >>> Thread 2 executes signal handler (0x20010400) >>> Thread 2 encountered an error: Interrupted system call (0x20010400) >>> Sending SIGUSR1 to thread 1 (0x20010360) >>> Thread 1 executes signal handler (0x20010360) >>> Thread 1 encountered an error: Interrupted system call (0x20010360) >>> Sending SIGUSR1 to thread 0 (0x200102c0) >>> Thread 0 executes signal handler (0x200102c0) >>> Thread 0 encountered an error: Interrupted system call (0x200102c0) >>> >>> Are the errors in the last test case to be expected under the 20130612 >>> snapshot (CYGWIN_NT-5.1, 1.7.21s 20130612 21:06:59, i686 Cygwin)? >> >> I can replicate this on my system, consistently. There's clearly a >> problem, but it's not the same as in the original Cygwin bug report. In >> the present case, the signal is received by the right thread, but >> something goes wrong afterwards. > > Try it on Linux. I don't see any difference. "An error" in this case > seems to be the script working as designed. > > % man sem_wait > > SEM_WAIT(3) Linux Programmer's Manual SEM_WAIT(3) > > > > NAME > sem_wait, sem_timedwait, sem_trywait - lock a semaphore > > ... > > ERRORS > EINTR The call was interrupted by a signal handler; see signal(7). Yeah, I missed that. Sorry for the noise. Ken