This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cvs cygwin1.dll


On Wed, 18 Sep 2002 15:35:53 -0400, Christopher Faylor <cgf@redhat.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@redhat.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@ntlworld.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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]