Mail Archives: cygwin-developers/2002/09/06/11:17:31
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
- Raw text -