DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; q=dns; s=default; b=Gf7WuAzVIHfERDI0JX+Ywnm0GDa+k
	CXJDgiF7hZU4ZeVOtQ+ycEGSpe7dyt2uoAr0feoRvcGP8cSCNSAPFI2pFVtEKv31
	6EG7ntfCq3H/STnYxHGMB5tZbfhV7HE/b45kXfl4qVKdGYLaRj9RMgc0TalZX6BG
	yqmGk6ir8xvU9M=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
From: "Lavrentiev, Anton (NIH/NLM/NCBI) [C]" <lavr@ncbi.nlm.nih.gov>
To: "cygwin@cygwin.com" <cygwin@cygwin.com>
Subject: RE: Tons of cygserver errors
Date: Wed, 2 Apr 2014 16:26:01 +0000
Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D0C8AC656@MLBXv04.nih.gov>
References: <5F8AAC04F9616747BC4CC0E803D5907D0C8AC056@MLBXv04.nih.gov> <20140402085347.GN2508@calimero.vinschen.de>
In-Reply-To: <20140402085347.GN2508@calimero.vinschen.de>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

> there's really no reason to quote that at all

Maybe, but how would I know that you did not need that?

> It means the pointer to the "signal_arrived" event object is invalid.
> "signal_arrived" is used internally to notify wait functions that a
> POSIX signal arrived for the process and to implement EINTR, for
> instance.  When you're using XSI IPC functions, the signal_arrived
> handle is used in cygserver to make the IPC functions interruptible.
> For that, it creates a local copy of signal_arrived using
> DuplicateHandle
> 
> For some reason the handle given to cygserver is invalid.  Why, I
> have no idea, and your report is missing information, so here we go
> again:

I can’t provide any further information at this point because I do not
understand what and where to look for.  But I have a slight clue that
there is a race in cygserver (and that's not unusual, from my experience).

There is a main process that has sems open / shm attached.  That process
fork()s and exec()s script every now and then.  If the main process
does not spawn any children, there is nothing in the log.  Once it starts
doing that, I see the errors coming in, and in good time correlation with
the spawning schedule.  The spawned processes are very short lived,
merely it's a fork, then exec a shell script with just an exit statement.

I suppose that when cygserver tries to read a handle, the child process
(which by posix rules had inherited the shm and sems, but should have
dropped them altogether at the point of exec()) is already gone, so the
handle is invalid.  Which is why it is the error "6" all way.

How realistic does that sound?

Anton Lavrentiev
Contractor NIH/NLM/NCBI