From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: Resources not freed
Date: Wed, 6 Dec 2006 20:16:23 -0000
Message-ID: <001101c71973$665490a0$a501a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <457432D0.8050407@bonhard.uklinux.net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On 04 December 2006 14:38, fergus wrote:

> Some Cygwin sessions (specifically those using "find" or "diff", and
> when the task is very great, as in say "diff -rq /largedisk1
> /largedisk2"*) I find that hogged resources are not freed when Cygwin is
> exit-ed. The egg-timer churns away on rather simple Explore requests,
> and there's lots of disk-hunting. The system never seems to recover.
> Usually I re-boot.

  You're going to have to explain a couple of things first.

1)  What "resources" you are referring to.
2)  How a win32 program could conceivably 'not free' those resources once it
has exited.

> As far back as 2003 and as recently as 2006 there are posts about this,
> with references to virtual memory, swap memory and so on, not being
> freed. It seems to be a subtly difficult problem to describe, or perhaps
> it wears many guises.

  Well, pretty much every single one of those claims turned out to be flat-out
wrong.  There is simply no way a cygwin process could do any such thing.  When
a process exits, the OS frees up any and all memory, file handles, etc. etc.,
that have been created for it.  There is no way round this, not even
deliberately, never mind by accident.  But read on: it might not be anything
cygwin does, but it might be something else in your system...

> 1. Have I identified a real phenomenon or am I imagining it?

  Hard to say.  You haven't described it in anything other than the vaguest of
terms yet.  If memory or file handles or something else were leaked, you
should be able to see something on task manager or process explorer or
similar.  The fact that you haven't attempted to measure anything and show us
a count of free/allocated X's that gets bigger or smaller in relation to this
problem leaves us with zero evidence to base our uninformed guesses on......
 
> 2. Can you characterise the class(es) of Cygwin activity most prone to
> cause this?

  Mu.  The question presupposes that 'this' actually happens, and that cygwin
activity causes it.  This is a deeply unscientific approach!  (cf. observer
bias, pet theories etc.)

> 3. Is there anything to be done to improve matters (eg, increasing RAM
> from 512M to 1G or even 2G)?

  Well.  There might be.

  Thing is, there is only one kind of entity in a modern (i.e. non-9x series)
windows that can ever leak anything, and that is a kernel-mode loaded module,
such as a device driver.

  If, after a long period of heavy cygwin activity, you find your system is
slugged, everything is paging all the time, and a reboot cures it, then the
most logical conclusion is that you have fallen victim to yet another
completely cruddy rubbbish buggy steaming-great-heap-of-mcaffee example of
faulty security software.

  I'm sure I remember one of those earlier threads you mention came to the
conclusion that there was a buggy anti-virus software, and the kernel-mode
device filter driver that it used to implement on-access file checking was
leaking file handles or pooled memory or something.  This would align with
your experience of things going wrong after a big find operation.

  So, the answer is to uninstall any/and/or/all of logitech process monitor,
agnitum outpost, and absolutely anything at all by norton or mcaffee, and any
of the non-free versions of zone alarm with the so-called 'helpful' advanced
behaviour monitoring and anti spyware functions, and then see if the problem
still occurs.


    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/