This is the mail archive of the cygwin 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: [OT] RE: Problems listing tasks under cygwin.


> -----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/


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