Mail Archives: cygwin/2002/09/20/07:29:33
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/
- Raw text -