[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pretest note

From: Carsten Mattner
Subject: Re: Pretest note
Date: Tue, 13 Mar 2012 10:02:59 +0100

On Tue, Mar 13, 2012 at 7:25 AM, Chong Yidong <address@hidden> wrote:
> Carsten Mattner <address@hidden> writes:
>> Don't we want to do something about the leak(s) or at least verify
>> down that they're correct "caching" or "reuse" behavior?
> AFAICT, this is Jan's report that memory is not returned to the system
> on Mac OS?  Obviously, if someone can help pin this down, that will be
> appreciated.  Yamamoto Mitsuharu gave one suggestion here:

While Jan was able to fix some obvious Cocoa issues and crashes,
this is not a Mac OS specific problem. I see the same extensive
non-reclaimed memory growth on Linux in both the X and terminal

> http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00358.html.
> Also, I'd like to know whether it really involves memory not being
> returned at all, independently of gnutls and networking.  For example,

No network or gnutls use in any of my Linux and OS X builds.

config options on Linux:
--without-selinux --without-tiff \
    --without-sound --without-dbus --without-gconf \
    --without-gsettings --without-xft --without-gsettings \
    --without-jpeg --without-gif --without-gpm \
    --with-x-toolkit=no --without-gnutls"

config options on Mac OS (to force building a 32-bit binary):
CFLAGS=$CFLAGS CC='gcc -arch i386' ./configure --with-ns --without-gnutls

Maybe I should also disable xml2 and png as those might be enabled.

> here is some Elisp code that visits a file and kills the buffer a few
> thousand times:
> (dotimes (n 50000)
>  (with-temp-buffer
>    (insert-file-contents "/path/to/emacs/etc/NEWS")))
> If Emacs on Mac OS really never returns memory, this should chew up all
> the memory on your system.  Does it?  Check also if Emacs 23 is
> affected.

If and only if that usage pattern is at fault, yes. I'll give it a try.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]