Mail Archives: cygwin/2012/10/26/14:37:44
X-Recipient: | archive-cygwin AT delorie DOT com
|
X-SWARE-Spam-Status: | No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS
|
X-Spam-Check-By: | sourceware.org
|
X-IronPortListener: | Outbound_SMTP
|
X-IronPort-Anti-Spam-Filtered: | true
|
X-IronPort-Anti-Spam-Result: | Av0EADPXilCcKEcU/2dsb2JhbABEwk6BCIIlEihRARUnAi8TJgEEGxqHZJtPhFScbZF+YQONK45QijaDCw
|
From: | "Lavrentiev, Anton (NIH/NLM/NCBI) [C]" <lavr AT ncbi DOT nlm DOT nih DOT gov>
|
To: | "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
|
Date: | Fri, 26 Oct 2012 14:36:42 -0400
|
Subject: | Possible race in SYSV IPC (semaphores)
|
Message-ID: | <A9D8BF3D8A74DF4A925FB541C0F39D2A17029755C5@NIHMLBX15.nih.gov>
|
MIME-Version: | 1.0
|
X-IsSubscribed: | yes
|
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
|
X-MIME-Autoconverted: | from quoted-printable to 8bit by delorie.com id q9QIbceY012518
|
Hi,
For now, I can only report the observed (mis) behavior of SYSV semop() call,
which (on the client side) gets manifested as the following:
transport_layer_pipes::connect: lost connection to cygserver, error = 2
(this code then does a by-hand adjustment with semctl(SETVAL)).
Note that there is a dedicated cygserver process running for my single-threaded
application.
Looking at the debugging output of cygserver, this is what I see in the log
(around the only time semctl() is logged there):
cygserver: /home/corinna/src/cygwin/cygwin-1.7.15/cygwin-1.7.15-1/src/cygwin-1.7.15/winsup/cygserver/transport_pipes.cc, line 132: Try to create named pipe: \\.\pipe\cygwin-13a7ed34cc1953a9-lpc
cygserver: /home/corinna/src/cygwin/cygwin-1.7.15/cygwin-1.7.15-1/src/cygwin-1.7.15/winsup/cygserver/transport_pipes.cc, line 132: Try to create named pipe: \\.\pipe\cygwin-13a7ed34cc1953a9-lpc
Note the double pipe creation call, and only a single "exit" log line such as:
cygserver: /home/corinna/src/cygwin/cygwin-1.7.15/cygwin-1.7.15-1/src/cygwin-1.7.15/winsup/cygserver/sem.cc, line 81: leaving (3416)
Cygserver does not stop (also, since SIGSYS is set to ignore in the program,
it also keeps running -- although, not always quite successfully once the semop()
failure occurred.)
The semaphore operations are very intensive; and involve arrays of 5 sems at
some times; also, there are quite large chunks of shmem updated every now
and then.
I studied the source of cygserver, and noticed that pipe_instance (transport_pipes.cc)
is not declared "volatile". This is strange because the compiler can rearrange lines
of code that include this variable, otherwise. And that seems rather critical.
Right now what I observe, is that SYSV IPC is unreliable, and I'm yet to figure
out why; the very same code (the locking logic) works on Linux/Solaris/Mac for
years and on thousands (yes, that many) of hosts. With CYGWIN the instability can
appear within a wide range of run time: from just a few minutes to some long hours,
rather randomly.
Any input can be greatly appreciated.
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
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 -