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

[Vladimir Sakharuk <vsakharuk at hbk dot com>]

One difference is that we are running(starting) up to 32 simultaneous instances of bash.exe/Cygwin on 32 core box.

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


Corinna


> 
> Thank you.
> 
> -----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.

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