This is the mail archive of the 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 <>

>On Wed, Sep 18, 2002 at 06:42:50PM +0000, Guy Harrison wrote:
>>On Fri, 13 Sep 2002 08:58:16 -0400, Christopher Faylor <>
>>>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 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
>> 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 - 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
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! ;-)


Unsubscribe info:
Bug reporting:

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