This is the mail archive of the
mailing list for the Cygwin project.
RE: bash and CSRSS consuming 100% of CPU
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: <cygwin at cygwin dot com>
- Date: Mon, 19 Jun 2006 19:00:13 +0100
- Subject: RE: bash and CSRSS consuming 100% of CPU
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.
[*] - ... 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