X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-10.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI
X-Spam-Check-By:	sourceware.org
From:	"Schmidt, Oliver" <oliv DOT schmidt AT sap DOT com>
To:	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Date:	Mon, 8 Mar 2010 18:35:02 +0100
Subject:	Cygwin 1.7: Concurrency Issue with Shared State Initialization
Message-ID:	<B10B50309DC54D45A855FD66F56015F71D07C78CAE@DEWDFECCR03.wdf.sap.corp>
MIME-Version:	1.0
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

Hi,

I think Cygwin 1.7 has a concurrency issue with the shared state initializa=
tion - which we experience because we use Cygwin in a probably untypical fa=
shion:

We call from a non-Cygwin shell a non-Cygwin gnumake. The Makefile rules mo=
stly call a non-Cygwin C compiler and linker. However Makefile rules callin=
g gawk, cat, cp, echo, mkdir, rm, sed, sh, ... are calling Cygwin executabl=
es.

If (and only if) we run gnumake in this scenario with the --jobs option to =
perform a parallel build then we experience sporadic failures of the Cygwin=
 executables. Fortunately these failures still happen now and then when run=
ning them with strace. So it was quite easy to find out that the shared var=
iable installation_root isn't correctly initialized when things go wrong.

Checking out src/winsup/cygwin/shared.cc I stumbled over these lines

    /* Initialize installation root dir. */
     if (!installation_root[0])
       init_installation_root ();

and thought that things might go wrong because several processes are callin=
g into init_installation_root() at the same time and was wondering why ther=
e's no kind of locking in place. I don't want to claim that this is the ver=
y root cause of the issue. However I tried to keep a Cygwin shell open in a=
nother window while running gnumake in order to have a stable shared state =
present for all Cygwin executables. I can definitively confirm that this sh=
ell makes in our scenario the difference between sporadic failure and smoot=
h operation of the Cygwin executables.

I'm sorry that I don't have a simple reproducible test case but I'm sure th=
at there IS a problem in that area - and it seems quite reasonable because
a) the code in question is quite new
b) most Cygwin users/testers most probable have some Cygwin executable cons=
tantly running or
c) don't start Cygwin executables in parallel thousand of times

Thanks in advance for your consideration.

Regards, Oliver Schmidt



--
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 -