Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <415B37E2.43789CCE@dessent.net> Date: Wed, 29 Sep 2004 15:32:02 -0700 From: Brian Dessent Organization: My own little world... MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Excessive CPU load (cygrunsrv.exe, tail.exe, etc) References: <20040929115032 DOT 98115 DOT qmail AT web52310 DOT mail DOT yahoo DOT com> <415AA557 DOT 14D51EFE AT dessent DOT net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Andrew DeFaria wrote: > In any event what version of Procexp do you use and suspect is causing > this problem. I have 5.20 running at home and I forget which version is > running at work but I know it's a newer version. > > When starting Procexp to check the version I noticed that he problem has > occurred again. csrss is taking ~20% and cron ~12%. The 2 inetd's are > taking ~10%. Working around this usually just involves a net stop of > cron/inetd and restarting it. OK that worked. Restarting Procexp and > wham! Same problem! Interesting. > > There is no modules view in 5.20 BTW. There is only View: DLLs and > Handles. Either setting causes this problem in Cygwin. "View DLLs" is what I meant by "module view." Same thing. The two ways that I've found to trigger it is to have the "bottom pane" active and set to DLL view and to click on a cygwin app, or double-click a cygwin app and select the "Threads" tab. In either case the thing that causes the problem is ProcExp attaching a thread to the Cygwin process in order to get the loaded modules and thread info. I've tried to track this down but it's quite hard to debug for several reasons: procexp does not come with source, it uses undocumented API calls, and it works in concert with csrss (which is a system service not a normal process and therefore harder to debug.) The closest I've been able to get is the following set of calls as seen in API Monitor: http://dessent.net/tmp/procexp-cygwin.gif Of course, I can't find any way to export that list to a plain text format, so this stupid screen shot is about the best I can do for now. If you look at the image it starts with a call to OpenProcess on pid 0xc9c which was my sacrificial Cygwin process. In this test I had only a single Cygwin process running, and this process was a brain dead hello-world type thing (a single call to read(0, buf, sizeof(buf)) so that it would just sit there and patiently block.) This test-app and those shown list of calls are the simplest test-case that I was able to narrow it down to. Brian -- 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/