> -----Original Message-----
> From: cygwin-owner On Behalf Of Brian Ford
> Sent: 19 May 2004 14:54
> On Wed, 19 May 2004, Brian Dessent wrote:
>
> > Although I'd still like to know why using ProcExp to list
> the handles*
>
> Nope, it is DLLs.
>
> > of any running Cygwin process causes the CPU to peg to 100%, and not
> > come down until cygwin1.dll is unloaded, i.e. kill all
> running cygwin
> > tasks and services. I've had to train myself when using ProcExp to
> > never accidently click on any Cygwin process, otherwise I have to go
> > through the annoying process of closing all rxvt's and stopping all
> > cygservices in order to get an idle CPU again...
>
> I don't quite see that. Only the process being explored runs away.
> After killing it, all is normal.
>
> > I've seen this reported to the list before but it got no replies.
>
> IIRC, I think I was the first to report it and you were the
> only one who
> replied. I haven't tried to fix it yet.
>
> > It started several notches back in the 1.5 series when there were a
> > large number of changes to the signal handling code, IIRC.
>
> Agreed.
A few data points:
The reason that the cygwin task behaves strangely has to be a consequence
of the actions of the thread that procexp/handleex attaches into it.
Perhaps we can find out more using apispy or similar. I can't see any
obvious reason why attaching a thread and messing with the process token
should cause problems, but maybe there's more to it than that.
When I saw this problem, ISTM that the cpu time was divided approx. 70/30
between the cygwin task and CSRSS.EXE; I think there must be a whole load of
client-server lpc thrashing going on between them.
When I ran handleex, it didn't even start up properly because a cygwin
(bash) process was hogging cpu; when I killed that process, handleex got
some time to run and promptly crashed with a NULL pointer dereference. This
came immediately after a failed call to
ntdll!RtlQueryProcessDebugInformation, i.e. the code sequence was
call ntdll!RtlQueryProcessDebugInformation
check return value, if non-zero continue elsewhere
load up a variable from the stack frame
dereference it.
so I suspect that something is going wrong in the debug subsystem (which
csrss has responsibility for forwarding).
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
