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
From: swamp-dog AT ntlworld DOT com (Guy Harrison)
To: cygwin AT cygwin DOT com
Subject: Re: cvs cygwin1.dll
Date: Fri, 20 Sep 2002 11:26:42 GMT
Message-ID: <3d8bf2b5.1540735@smtp.ntlworld.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>
In-Reply-To: <20020918193553.GA9328@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g8KBTWM02071

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.

It just will not be debugged. Attaching a debugger after the fact isn't
possible. Not limited to gdb: borland builder, borland tdb, W32dsm87
(some disassembler I didn't know I had) and VC6 all refuse to attach to
the hung process. Faced with this I compiled 'ash' and 'make' then
followed the top level 'make'. Doesn't break. The act of debugging
"fixes" the problem. I tried strace again: liberated the 0x2000 STRACE
flag and implemented a user_printf() such that I could insert things at
choice places in order to drastically reduce output. No joy. After all,
debuggers have to stop/start threads but it was worth a whirl.

Since then I've been dumping data direct to a file via the WinAPI. Doing
this does have some minor side-effects on behaviour, depending where and
how much stuff I write, but at least it still hangs. The file tends to
end up huge. Too much to get a grip on. It would help if I could confirm
some things...

I see ::ExitProcess() in only pinfo.cc - assuming I keep my grubby
fingers off the keyboard, is this the only place a process will exit or
are there "normal" situations in which ::TerminateProcess() gets called
(which ones)?

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
::ExitProcess()?
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.

Similarly, anyone know or heard of, issues reguarding an active main
thread yielding to another active thread within ::ExitProcess()?

The cygthread::stub (info->func) itself: are any of these allowed to be
still running when the process exits?

Can Spy++ from VC6 be trusted? I need to ask because VC itself was the
only debugger that crashed more often than issue a refusal to attach.
Some info here would be good. Spy++ is the only tool I've got which
tells me the state of the thread. Links to better tools welcomed! ;-)


-- 
swamp-dog AT ntlworld DOT com

--
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/