Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Sun, 8 Sep 2002 13:00:46 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: hang in sig_wait waiting for debug lock
Message-ID: <20020908170046.GB7279@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <7710998905 DOT 20020828173811 AT logos-m DOT ru> <20020905153320 DOT GC16827 AT redhat DOT com> <591948241 DOT 20020906185459 AT logos-m DOT ru> <20020906151713 DOT GC21699 AT redhat DOT com> <1176882135 DOT 20020906201713 AT logos-m DOT ru> <20020906210506 DOT GB26002 AT redhat DOT com> <195826558 DOT 20020908204151 AT logos-m DOT ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <195826558.20020908204151@logos-m.ru>
User-Agent: Mutt/1.4i

On Sun, Sep 08, 2002 at 08:41:51PM +0400, egor duda wrote:
>CF>I don't see this either.  If the table is populated with handles from
>CF>another process that don't exist in this one then that's a bug.
>
>It's clearly so. And enabling setclexec() removes it.

Well, I just walked my dog around the block and I don't see it
happening so I guess it is somehow related to my dog, too.

>I can guess, that it's not the way things were supposed to work, right?

Come on!  Unless you can point to an actual flow of control which
is causing the problem, turning random things on and saying "Wow!
That fixes the problem!" is just voodoo.  It isn't computer science.

If you don't want to understand what's going on then that is perfectly
fine.  However, please don't just assume that if turning on an ifdef
causes a problem to apparently go away that you've done anything more
than add an additional delay to cygwin or moved something to a different
memory location or something.

I am not saying that handles aren't somehow being inherited from
a parent process (which is the only way I can conceive of something like
this happening) but you haven't proved that to be true until you've
pointed to an actual handle for which this is a problem.

Turning on this ifdef causes other random problems.  It is not a solution
for anything.

>CF> Possibly.  Are you seeing system_printf output in your failing case?
>
>Yes, but it looks that it not full. Actually, pipe hasn't to be filled
>up. After WriteFile() we call FlushFileBuffers (). Documentation on
>FlushFileBuffers states that if handle is a pipe then the operation
>blocks until pipe peer reads _all_ data from pipe. Commenting
>FlushFileBuffers did helped in my case -- system_printf()s are not
>blocking process now.
>
>Yet i suppose the right way is to always unlock debug muto as fast as
>possible, i.e., before calling debug_printf() and stuff. As far as i
>understand, muto is protecting handle list, so we must hold it while
>and only while we're messing with it. That should be safe.

Possibly.  Personally, I'm much more bothered by the fact that there
are system_printfs at all.  AFAICT, you only mention this in passing
but a system_printf is an indication of a problem in cygwin.

cgf