X-Spam-Check-By: sourceware.org
Date: Mon, 14 Aug 2006 06:20:29 +0300
Message-Id: <u8xlsf1fm.fsf@gnu.org>
From: Eli Zaretskii <eliz AT gnu DOT org>
To: "emacs user" <emacs_user AT hotmail DOT com>
CC: cygwin AT cygwin DOT com, emacs-pretest-bug AT gnu DOT org, hack AT robf DOT de
In-reply-to: <BAY107-F206BD6C70F398FE226373DF8490@phx.gbl> 	(emacs_user@hotmail.com)
Subject: Re: reproducible cygwin memory problems
Reply-to: Eli Zaretskii <eliz AT gnu DOT org>
References:  <BAY107-F206BD6C70F398FE226373DF8490 AT phx DOT gbl>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

> From: "emacs user" <emacs_user AT hotmail DOT com>
> Bcc: 
> Date: Sun, 13 Aug 2006 17:32:38 -0400
> 
> >From: Eli Zaretskii <eliz AT gnu DOT org>
> 
> >If I don't miss anything, it remains to be explained why the OP didn't
> >see problems with normal buffers.  Could the OP please try visiting
> >several large text files, then kill their buffers, invoke the
> >`garbage-collect' function ("M-x garbage-collect RET"), and see if the
> >memory footprint returns to its original value?
> 
> starting emacs -Q: 12,832k
> editing a large test file (43,085,936), emacs memory goes up to 55,028k
> killing : emacs uses 13,070
> and M-x garbage-collect 13,100 or so,
> 
> so far it seems that tmemory is returned.

Yes.

> however, using emacs a bit more, 
> opening and killing buffers, eventually does lead to memory increase even 
> after I kill all buffers and do garbage-collect.

Assuming that ``using a bit more'' loads some Lisp packages, this is
normal.  Also, font-lock, which works in the background, adds text
properties to buffers, which also uses up some memory.

> >A few more tests come to mind:
> >
> >   . Put a breakpoint in sbrk and in mmap, and find out which one is
> >     being called when normal text files and image files (both small
> >     and large) are visited.
> 
> could you please write which .c files and which routines should I be looking 
> at slightly more specifically?  thanks...

These are library functions, so no .c files are involved.  Just

  (gdb) break sbrk
  (gdb) break mmap

then visit text and image files as suggested and see which of these
breakpoint actually breaks.

> >   . Visit many small image files (smaller than 256K) and see whether
> >     the memory is being returned to the OS.

Same here.

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