Re: Pretest note

[Carsten Mattner <carstenmattner@googlemail.com>]

On Tue, Mar 13, 2012 at 10:02 AM, Carsten Mattner
<carstenmattner@googlemail.com> wrote:
> On Tue, Mar 13, 2012 at 7:25 AM, Chong Yidong <cyd@gnu.org> wrote:
>> Carsten Mattner <carstenmattner@googlemail.com> 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
> client.
>
>> 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.

Let's not forget that I'd like to use --daemon, but that's not practical
as long as I don't have more physical memory or the leak is
plugged.

<seriously>
If we don't find the problem, I'm not insisting on delaying the release
for me personally. I'm fine tracking bzr and restarting Emacs on an
hourly basis to try one of the two daily rebuilds. I'm used to it.
</seriously>

<rant>
A shorter release cycle would remove the pressure, especially
as most users seem to have enough physical memory to not
care about the leak or fast enough machines to live with the
cc-mode performance regressions. More users should ideally
equal more testers and more useful feedback.
</rant>

Chong, thanks for taking this seriously and writing it off as ghosts
seen by a couple users.