On Wed, 18 Sep 2002 15:35:53 -0400, Christopher Faylor <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >>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! ;-) -- [EMAIL PROTECTED] -- 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/
