This is the mail archive of the
mailing list for the Cygwin project.
Re: cvs cygwin1.dll
On Fri, Sep 20, 2002 at 11:26:42AM +0000, Guy Harrison wrote:
>On Wed, 18 Sep 2002 15:35:53 -0400, Christopher Faylor <firstname.lastname@example.org>
>>On Wed, Sep 18, 2002 at 06:42:50PM +0000, Guy Harrison wrote:
>>>On Fri, 13 Sep 2002 08:58:16 -0400, Christopher Faylor <email@example.com>
>>>>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 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?
>Anyone know, or heard of, issues reguarding suspended threads and
Deadlocks with thread or process attach/detach code are documented in
>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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html