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: Fri, 6 Sep 2002 11:17:13 -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: <20020906151713.GC21699@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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <591948241.20020906185459@logos-m.ru>
User-Agent: Mutt/1.4i

On Fri, Sep 06, 2002 at 06:54:59PM +0400, egor duda wrote:
>Hi!
>
>Thursday, 05 September, 2002 Christopher Faylor cgf AT redhat DOT com wrote:
>
>CF> Any word on this?  Have you determined which thread has the lock?
>CF> It should be easy to do by looking at the muto structure.
>
>I'm having a hard time trying to reproduce this reliably. This change
>
>Index: debug.cc
>===================================================================
>RCS file: /cvs/uberbaum/winsup/cygwin/debug.cc,v
>retrieving revision 1.39
>diff -u -p -2 -r1.39 debug.cc
>--- debug.cc    6 Aug 2002 03:40:40 -0000       1.39
>+++ debug.cc    6 Sep 2002 12:24:09 -0000
>@@ -79,5 +79,5 @@ out:
> }
> 
>-#ifdef DEBUGGING_AND_FDS_PROTECTED
>+#ifdef DEBUGGING
> void
> setclexec (HANDLE oh, HANDLE nh, bool not_inheriting)
>Index: fhandler.cc
>===================================================================
>RCS file: /cvs/uberbaum/winsup/cygwin/fhandler.cc,v
>retrieving revision 1.134
>diff -u -p -2 -r1.134 fhandler.cc
>--- fhandler.cc 30 Aug 2002 15:47:09 -0000      1.134
>+++ fhandler.cc 6 Sep 2002 12:24:10 -0000
>@@ -1172,7 +1172,9 @@ void
> fhandler_base::set_inheritance (HANDLE &h, int not_inheriting)
> {
>-#ifdef DEBUGGING_AND_FDS_PROTECTED
>+#ifdef DEBUGGING
>   HANDLE oh = h;
> #endif
>+  if (!h) 
>+    return;
>   /* Note that we could use SetHandleInformation here but it is not available
>      on all platforms.  Test cases seem to indicate that using DuplicateHandle
>@@ -1183,5 +1185,5 @@ fhandler_base::set_inheritance (HANDLE &
>                             DUPLICATE_SAME_ACCESS | DUPLICATE_CLOSE_SOURCE))
>     debug_printf ("DuplicateHandle failed, %E");
>-#ifdef DEBUGGING_AND_FDS_PROTECTED
>+#ifdef DEBUGGING
>   if (h)
>     setclexec (oh, h, not_inheriting);
>
>eliminates a host of strange errors i've seen in debugging mode,
>including a debug muto one.
>
>Changelog states, however, that setclexec stuff isn't needed. Yet i
>can't see why we shouldn't process protected handle list as long as we
>recreating handles during set-close-on-exec operation. Can you give a
>comment?

I assume that you mean this entry:

2002-07-14  Christopher Faylor  <cgf AT redhat DOT com>

        * dcrt0.cc (dll_crt0_1): Move debug_init call back to here.  Avoid a
        compiler warning.
        * shared.cc (memory_init): Remove debug_init call.
        * debug.h (handle_list): Change "clexec" to "inherited".
        * debug.cc: Remove a spurious declaration.
        (setclexec): Conditionalize away since it is currently unused.
        (add_handle): Use inherited field rather than clexec.
        (debug_fixup_after_fork_exec): Ditto.  Move debugging output to
        delete_handle.
        (delete_handle): Add debugging output.
        * fhandler.cc (fhandler_base::set_inheritance): Don't bother setting
        inheritance in debugging table since the handle was never protected
        anyway.
        (fhandler_base::fork_fixup): Ditto.

I'm at a loss to understand why adding additional things into the
protected handle table would solve a race.  There are too many places
where the fd handle is manipulated but not protected for this code
to be turned on.  And since there is no easy way to get distinct handle
name information into the table, it wouldn't make sense to add the
protection anyway.

cgf