X-Spam-Check-By: sourceware.org
Date: Sat, 12 Aug 2006 17:52:38 +0300
Message-Id: <uoduqc8g9.fsf@gnu.org>
From: Eli Zaretskii <eliz AT gnu DOT org>
To: "emacs user" <emacs_user AT hotmail DOT com>
CC: emacs-pretest-bug AT gnu DOT org, cygwin AT cygwin DOT com
In-reply-to: <BAY107-F22549D794C527187392FB2F8480@phx.gbl> 	(emacs_user@hotmail.com)
Subject: Re: reproducible cygwin memory problems
Reply-to: Eli Zaretskii <eliz AT gnu DOT org>
References:  <BAY107-F22549D794C527187392FB2F8480 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

[I'm not subscribed to the Cygwin list, so please CC me directly.]

> From: "emacs user" <emacs_user AT hotmail DOT com>
> Bcc: 
> Date: Sat, 12 Aug 2006 07:46:33 -0400
> Cc: cygwin AT cygwin DOT com
> 
> Eli, here is a response from the cygwin list. thanks to Reini Urban for 
> this.
> 
> Look Eli,
> that's really a bold statement, esp. when elisp is involved.
> cygwin uses the newlib libc. How does it come to your mind that newlib's
> free() and subsequently Microsoft's VirtualFree (,MEM_RELEASE) doesn't
> work as advertised?
> Please see the src for newlib's free() at src/newlib/libc/stdlib/mallocr.c
> http://cygwin.com/cgi-bin/cvsweb.cgi/src/newlib/libc/stdlib/mallocr.c?rev=1.15&content-type=text/x-cvsweb-markup&cvsroot=src
> 
> 
> POSIX free() is not like perl or lisp, where there's no such concept of
> free(), if by lazyness or better strategies.
> 
> POSIX free() and cygwin's free() does give back it's malloc'ed buffers
> back to the OS, and the OS does list them correctly as free.
> 
> What you have here is an ELISP issue, which doesn't free it's interim's
> memory, and you falsely accuse the C part of the image library. Please
> have a look again in some lisp allocated buffers and then check if some
> free() is missing.

It's possible that I'm wrong, of course.  Let me state the facts and
observations that led me to my conclusion:

  . The OP reported that the problem happens only with image files.
    When he edits text files, the Emacs memory footprint stays at a
    reasonable value.

  . After killing the image buffer, the OP invoked the Lisp function
    clear-image-cache, which is supposed to release any memory used by
    Emacs for storing images.  There's no other Lisp memory that I can
    see in the sources that is used for images, and that could be left
    unreleased.  To be sure, I'd like to ask emacs_user AT hotmail DOT com,
    who is the OP, to invoke "M-x garbage-collect RET" after
    clear-image-cache, and see if that changes anything.

  . The OP traced the Emacs code in clear-image-cache, and saw that
    the function in the image libraries that frees the image is indeed
    called.

  . Other Emacs builds, including the native Windows build and a
    GNU/Linux build, do not exhibit this behavior.

Given these observations, and the fact that the Cygwin build of Emacs
runs almost the same C and Lisp code as the GNU/Linux build, what
other factors can be involved 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/