This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Mar 9 16:12, Vladimir Sakharuk wrote: > > -----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 > > > > 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. > > > > > > 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 there any way to check if rebase successful?) > > > > That's not a rebase problem. It's apparently a concurrency problem > > of sorts. While pulling up the per-user shared memory region, two > > or more processes are trying to set up the same mount points. > > > > This is not supposed to happen. Only the first process actually > > *creating* the per-user shared memory is supposed to create the > > mount points. The OS tells a process if it created or just opened a > > shared memory region, but for some reason both processes seem to > > think they created the shmem region and one of them then stumbles of > > the EPERM condition trying to create the root mount point twice. > > > > > Thank you for suggestions. > > > > I don't have a sugggestion, in fact. Again, this error condition was supposed to be impossible, but somehow it isn't in your cluster setup. > > -----Original Message----- > From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of Corinna Vinschen > Sent: Monday, March 09, 2015 5:18 AM > To: cygwin@cygwin.com > Subject: Re: bash.exe: *** fatal error - add_item ("\??\C:\cygwin", "/", ...) failed, errno 1 > > 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. > One difference is that we are running(starting) up to 32 simultaneous > instances of bash.exe/Cygwin on 32 core box. Shouldn't make a difference since that's what the Interlocked operations are meant for. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
pgp5bA9xx5sMk.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |