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]

Re: bash.exe: *** fatal error - add_item ("\??\C:\cygwin", "/", ...) failed, errno 1


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]