X-Spam-Check-By: sourceware.org From: "Dave Korn" To: Subject: RE: bash and CSRSS consuming 100% of CPU Date: Mon, 19 Jun 2006 19:00:13 +0100 Message-ID: <005601c693ca$36b44ae0$a501a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: 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 On 19 June 2006 18:44, Charli Li wrote: > The reason for the Z-Shell, if Dave, cgf, or Corinna is asking, is because > bash may be a little buggy. The only problem that I know of (yours) is > reported against bash (perhaps anybody would like to reference more bash > problems???), and a problem has been reported against pdksh (ksh). No > problems that I know of have been reported against ash, tcsh, or zsh. No, you're wrong about that. The procexp-100%-CPU thing affected absolutely /any/ cygwin process that you attempted to view the threads info for. Absolutely any cygwin process, and regardless of whether it was launched from a bash shell or any other shell or cmd.exe or no shell at all. Further, it was tracked down and understood: it was a problem with some risky behaviour in the DLL_THREAD_ATTACH callback of the cygwin dll that didn't play well with the expectations of the remote thread procedures injected by the debug-helper API. There is no evidence that this is a bash problem, and it would be an incredible coincidence if there was a bug in bash that just happened to produce the exact same effects as the bug that we /know/ there was in the dll. > And yes, please disable Symantec, as Dave said, since security > suites/products are a pain in the neck for Cygwin! As they've got more advanced, they've introduced features that attempt to do more than your standard anti-virus-scan-on-opening-a-file; they attempt to block some of the dangerous behaviours that malwares use, such as (for example) injecting a thread into a process that is known to have firewall permissions. But because these behaviours are implemented using standard windows system library features, there is no simple way to block them without risking interfering with the operations of standard software that happens to use the same APIs for non-malicious purposes. This also explains why some ZoneAlarm users report tremendous problems with cygwin and others report it working fine. The free version of Zone Alarm works great with cygwin; but the paid-for version (Zone Alarm Pro) has "advanced"[*] behaviour-blocking features that interfere very badly. cheers, DaveK [*] - ... which, since it was better off without them, should be considered an 'advance' only in the one-step-forward-two-steps-backward scheme of things ... -- 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/