DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=OWEt93w377BX27K9mrt3I3/YaNRiERAdXL8dxceZhKXC/OsWJ8X5l
	wG2bSUGFHKVxPbLMKIPsflgEkWOa1NQ0CPNXomoknhEyIZDw89K/Z03yWDtJ9s+7
	FepklgftV9bh1RT2KMf5dsw9F1mt05WPrsCZQAFJWIXKW7CNJ5wZU4=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Mon, 9 Mar 2015 10:18:06 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: bash.exe: *** fatal error - add_item ("\??\C:\cygwin", "/", ...) failed, errno 1
Message-ID: <20150309091806.GC28200@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <33B440E9970A984C93230FC4FA9B70ECCF1964@DALIFXMB1.hbk.com> <33B440E9970A984C93230FC4FA9B70ECCF19A0@DALIFXMB1.hbk.com> <20150305170349.GI3213@calimero.vinschen.de> <33B440E9970A984C93230FC4FA9B70ECCF225E@DALIFXMB1.hbk.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="FsscpQKzF/jJk6ya"
Content-Disposition: inline
In-Reply-To: <33B440E9970A984C93230FC4FA9B70ECCF225E@DALIFXMB1.hbk.com>
User-Agent: Mutt/1.5.23 (2014-03-12)

--FsscpQKzF/jJk6ya
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mar  5 21:30, Vladimir Sakharuk wrote:
> That was helpful! I have stopped trying rebase combinations and
> looking for something else...

It wasn't all that helpful I think.  My description of what happens
was rather off.  Actually the fact if a process has created or just
opened the shared mem region isn't checked at this point in time.
Rather, a spinlock is used to generate exclusive access to the shared
mem region at initilization time.
This spinlock implementation, basically using the InterlockedExchange
call at its code, has served us well in the past, but something in your
cluster setup appears to break it, though I can't imagine how.


Corinna


>=20
> Thank you.
>=20
> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf =
Of Corinna Vinschen
> Sent: Thursday, March 05, 2015 12:04 PM
> To: cygwin@cygwin.com
> Subject: Re: bash.exe: *** fatal error - add_item ("\??\C:\cygwin", "/", =
...) failed, errno 1
>=20
> On Mar  5 15:40, Vladimir Sakharuk wrote:
> > Hi All,
> > I have found similar issues, but did not find solution that worked for =
me. Looking for help.
> >=20
> > I am trying to run applications on windows cluster.
> > I am getting random crashes like bellow.
> > However most of the times it works. I assume around 1% of starts fails.=
 Starting it is again usually succeed.
> > I suspected that it was forking issue, but cygwin's rebase did not help.
> > I did rebase after server reboot with no Cygwin apps running. (BTW, Is=
=20
> > there any way to check if rebase successful?)
>=20
> That's not a rebase problem.  It's apparently a concurrency problem of so=
rts.  While pulling up the per-user shared memory region, two or more proce=
sses are trying to set up the same mount points.
>=20
> This is not supposed to happen.  Only the first process actually
> *creating* the per-user shared memory is supposed to create the mount poi=
nts.  The OS tells a process if it created or just opened a shared memory r=
egion, but for some reason both processes seem to think they created the sh=
mem region and one of them then stumbles of the EPERM condition trying to c=
reate the root mount point twice.
>=20
> > Thank you for suggestions.
>=20
> I don't have a sugggestion, in fact.  Again, this error condition was sup=
posed to be impossible, but somehow it isn't in your cluster setup.

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--FsscpQKzF/jJk6ya
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJU/WVOAAoJEPU2Bp2uRE+guYwP/iQZxmHq4OCmUMiZWXUxDXnY
AzIjuCdVmZKTkHYp8FlybSPEoleHcI9RFDCZyOJ+fQlbrMZIROUhSPpN6eis0GMh
1wUlY5VDKqZcu9k8RgiUs6nrF/24xDgzyfRTwPwFnesY47XOPXfbQafJVrtOsLgU
Py6Z2fj73nNRBzCqduPqX+9+FnRKCaORaFUrGqoaqrCWtdPLgbaLvT+e52ukArdG
vYwHQqexSwec2vHxPcYfOSf7eiH1HlaNoTXlv8/USWMOZXokBHShlUjMG+IuEDGN
sc+/WlMzDOPoQ710RLct5uXAwXmMLVHO8gvTRFzEezB0y5O216aRdIiMp3pp1s4h
zyzL1sWVJFk2XmVq+e8SEF+m/SX0eX0UA6aXk0vMimaC0nujyzPUM5gtIBkVkrPW
/a1pHB8b320f1xSITUxqfRw0us0gJ7ajZc1AYo4+Q9QGc8VdN+/zv+VwJa0VJFIU
RBT3EgUQM3oi7PukEOFf9hzrTSekvZa7v2k8BQ3D3cslb20MYheTdh++4txbCdvj
cMN/S7I62GyQDE/lEh0rWhdlFphvJ8BNyDooqDp77hcEON2r4SOMrUqu4l103MUu
qIqK4nEn70Zcabb2zO2TQvXbIjvyJ8mD2yh5QIM3DrkxoXxlX2WymVHSx5Bv+Bk9
rou5qVxx8M2D1m14jcI5
=XakU
-----END PGP SIGNATURE-----

--FsscpQKzF/jJk6ya--