Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Fri, 20 Sep 2002 11:56:57 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: cvs cygwin1.dll
Message-ID: <20020920155657.GH24740@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <3d81aa1b DOT 1496411 AT smtp DOT ntlworld DOT com> <20020913125816 DOT GA1030 AT redhat DOT com> <3d88c6c1 DOT 17117483 AT smtp DOT ntlworld DOT com> <20020918193553 DOT GA9328 AT redhat DOT com> <3d8bf2b5 DOT 1540735 AT smtp DOT ntlworld DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3d8bf2b5.1540735@smtp.ntlworld.com>
User-Agent: Mutt/1.4i

On Fri, Sep 20, 2002 at 11:26:42AM +0000, Guy Harrison wrote:
>On Wed, 18 Sep 2002 15:35:53 -0400, Christopher Faylor <cgf AT redhat DOT com>
>wrote:
>
>>On Wed, Sep 18, 2002 at 06:42:50PM +0000, Guy Harrison wrote:
>>>On Fri, 13 Sep 2002 08:58:16 -0400, Christopher Faylor <cgf AT redhat DOT com>
>>>wrote:
>>>
>>>>On Fri, Sep 13, 2002 at 09:09:37AM +0000, Guy Harrison wrote:
>>>>>I can't seem to figure out how to set a breakpoint in sigproc.cc without
>>>>>recompiling make with debug. Any hints?
>>>>
>>>>Just attach to the running process and set a breakpoint.
>>>>
>>>>Alternatively, use the "dll" command to load cygwin1.dll and then set
>>>>a breakpoint on a *line number*.
>>>
>>>Thanks, the latter helped verify that debugging made the problem go away
>>>- ditto strace. Initially I thought it was a race. Racing certainly
>>>helps trigger it but that isn't the problem.
>>>
>>>I can't see a mechanism involving cygthread::stub to cater for the case
>>>where "last man out"+1 ensures "last man out" is running. In all
>>>situations where abnormal behaviour occurs we're left waiting upon a
>>>process that consists of a single suspended cygthread::stub thread.
>>>Others should be able to verify this by bumping up the size of the
>>>cygthread.cc threads[] array up to a silly value then attempt an
>>>intensive configure/make/install with it. Conversely now that I've set
>>>threads[1] there's been no breakages.
>>
>>Where are you seeing this wait?  Details please.
>
>Any reasonably intensive configure/make/install build. Not surprising
>'cos that's what I do most. Name almost any process that occurs during
>that and its had a hang on a lone suspended thread - all the parent
>processes waiting on it. Spurious.

The "where" meant where in the code.

You apparently tracked things down to the cygthread code but I don't
see any real analysis of why the cygthread code would cause this.  The
fact that you twiddled something and the problem went away does not
necessarily mean that you've found the source of the problem -- not
in any complex system at least.

I suspect that this is actualy due to a deadlock in the code init.cc
which was recently discussed in cygwin-developers.

>The implication is that cygthread::stub's should be in suspended state
>as the process exits. Is this (a) correct, (b) expected, (c) required?

a, b.

>Anyone know, or heard of, issues reguarding suspended threads and
>::ExitProcess()?

Deadlocks with thread or process attach/detach code are documented in
MSDN.

>Possibles that come to mind - winAPI bug whereby a suspended thread can
>be momentarily woken (ie enough to become the main thread), or perhaps a
>suspended thread can linger due to a handle being left open on it and
>therby become the main thread.

I don't think it has anything to do with suspended threads.  You can
certainly verify this by adding code to kill the threads specifically,
though, and see what happens.

The deadlock would be more likely if there are more threads and with the
new cygthread code there will always be at least six extra threads.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/