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 18:54:59 +0400
From:	egor duda <deo AT logos-m DOT ru>
Reply-To:	egor duda <cygwin-developers AT cygwin DOT com>
Organization:	deo
X-Priority:	3 (Normal)
Message-ID:	<591948241.20020906185459@logos-m.ru>
To:	Christopher Faylor <cygwin-developers AT cygwin DOT com>
Subject:	Re: hang in sig_wait waiting for debug lock
In-Reply-To:	<20020905153320.GC16827@redhat.com>
References:	<7710998905 DOT 20020828173811 AT logos-m DOT ru>
	<20020905153320 DOT GC16827 AT redhat DOT com>
MIME-Version:	1.0

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?

Egor.            mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19

- Raw text -