* Memory Leak was: Re: Update on the Emacs release schedule? 8 messages
@ 2012-01-08 3:28 T. V. Raman
2012-01-08 14:23 ` Stefan Monnier
2012-01-25 14:52 ` Nix
0 siblings, 2 replies; 5+ messages in thread
From: T. V. Raman @ 2012-01-08 3:28 UTC (permalink / raw)
To: emacs-devel
I'm running Emacs 24 on three machines, and am seeing leaks on
one of them -- Details below.
Home: Ubuntu Jaunty x86_32 quad-core -- No Leak
Laptop: Intel x86_64 dual core Ubuntu Lucid -- No Leak
Work: amd_64 16-core HP workstation Ubuntu Lucid -- Leak!
I know other Emacs hackers at work who are running the identical
Lucid build on 64-bit machines -- but not on the 16-core HP
workstation who are not seeing the leak.
I've tried building with and without gnutls -- no difference.
Symptoms of the leak:
The office workstation has 12gb of RAM and 36GB swap.
Before starting Emacs: `free' shows 2gb in use.
Start Emacs 24 -- with just emacspeak loaded -- no immediate
signs of a leak -- `free' shows abut 6gb in use -- which does
seem a lot.
M-x shell in that emacs
and wait for a couple of minutes.
Running `free' on a separate terminal shows that all 12GB of
memory in use -- emacs RSS is at 10GB.
If you dont kill the runnning emacs-24 at that point, it brings
the workstation to its knees and the machine stops responding and
needs to be rebooted.
--Raman
--
Best Regards,
--raman
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Memory Leak was: Re: Update on the Emacs release schedule? 8 messages
2012-01-08 3:28 Memory Leak was: Re: Update on the Emacs release schedule? 8 messages T. V. Raman
@ 2012-01-08 14:23 ` Stefan Monnier
2012-01-18 0:39 ` T.V. Raman
2012-01-25 19:36 ` T.V. Raman
2012-01-25 14:52 ` Nix
1 sibling, 2 replies; 5+ messages in thread
From: Stefan Monnier @ 2012-01-08 14:23 UTC (permalink / raw)
To: tv.raman.tv; +Cc: emacs-devel
> Before starting Emacs: `free' shows 2gb in use.
FWIW, "free" is not a very good tool to track the memory use of
a specific process. Better check the VSZ and RSS of the process itself
(and note that RSS can stay stable even in the presence of a leak,
so VSZ is important).
> Start Emacs 24 -- with just emacspeak loaded -- no immediate
> signs of a leak -- `free' shows abut 6gb in use -- which does
> seem a lot.
What is Emacs's RSS and/or VSZ at startup?
> M-x shell in that emacs
> and wait for a couple of minutes.
> Running `free' on a separate terminal shows that all 12GB of
> memory in use -- emacs RSS is at 10GB.
> If you dont kill the runnning emacs-24 at that point, it brings
> the workstation to its knees and the machine stops responding and
> needs to be rebooted.
So you're saying that "emacs -Q" plus emacspeak plus "M-x shell" results
on this machine in a process hat keeps growing even if you leave
it alone?
Could you run it under GDB (from the `emacs/src' directory) and
interrupt the process (with C-z) every once in a while to try and see
what it's doing?
Stefan
^ permalink raw reply [flat|nested] 5+ messages in thread
* Memory Leak was: Re: Update on the Emacs release schedule? 8 messages
2012-01-08 14:23 ` Stefan Monnier
@ 2012-01-18 0:39 ` T.V. Raman
2012-01-25 19:36 ` T.V. Raman
1 sibling, 0 replies; 5+ messages in thread
From: T.V. Raman @ 2012-01-18 0:39 UTC (permalink / raw)
To: Stefan Monnier, emacs-devel
Stephane,
Unfortunately, Emacspeak is what talks to me, so it's well-nigh
impossible for me to debug emacs with GDB.
But here are a few additional bits of info that might help:
RSS etc that I reported were from proced in emacs ---
also, it's hard to get any useful info out snce the workstation
crashes or becomes unusable fairly rapidly.
I'm attaching two other bits of information that may be useful:
The binary src/emacs is approx 13mb big on my laptop and home
machines where I dont see the leak -- 7mb after
stripping. Constrast this with the numbers I see on the machine
where I do see the leak -- 19mb before stripping, 12mb+ after
stripping. I'll also attach the output of ldd on the offending
machine in case that sheds any light.
ls -l src/emacs
-rwxr-x--- 3 raman eng 19612869 2012-01-06 15:37 src/emacs*
16:34:49 retriever emacs $ strip src/emacs
16:34:56 retriever emacs $ !ls
ls -l src/emacs
-rwxr-x--- 3 raman eng 12707840 2012-01-17 16:34 src/emacs*
16:35:01 retriever emacs $ ldd src/emacs
linux-vdso.so.1 => (0x00007fff4bf8b000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00007f2ef3ae6000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00007f2ef3839000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00007f2ef3617000)
libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007f2ef3363000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00007f2ef3139000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00007f2ef2f1c000)
libm.so.6 => /lib/libm.so.6 (0x00007f2ef2c99000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00007f2ef2a8c000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007f2ef2808000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00007f2ef25be000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f2ef2338000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f2ef2102000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f2ef1eba000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f2ef1cb6000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007f2ef1ab0000)
librt.so.1 => /lib/librt.so.1 (0x00007f2ef18a8000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00007f2ef15ca000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x00007f2ef13c0000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x00007f2ef11a5000)
libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00007f2ef0f43000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00007f2ef0d1e000)
libpng12.so.0 => /lib/libpng12.so.0 (0x00007f2ef0af7000)
libz.so.1 => /lib/libz.so.1 (0x00007f2ef08e0000)
libgif.so.4 => /usr/lib/libgif.so.4 (0x00007f2ef06d6000)
libXpm.so.4 => /usr/lib/libXpm.so.4 (0x00007f2ef04c5000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f2ef018f000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f2eeff84000)
libXft.so.2 => /usr/lib/libXft.so.2 (0x00007f2eefd6f000)
libasound.so.2 => /usr/lib/libasound.so.2 (0x00007f2eefa8e000)
librsvg-2.so.2 => /usr/lib/librsvg-2.so.2 (0x00007f2eef856000)
libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x00007f2eef617000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f2eef3fa000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00007f2eef0a9000)
libgpm.so.2 => /usr/lib/libgpm.so.2 (0x00007f2eeeea2000)
libncurses.so.5 => /lib/libncurses.so.5 (0x00007f2eeec5f000)
libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x00007f2eeea21000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00007f2eee803000)
libotf.so.0 => /usr/lib/libotf.so.0 (0x00007f2eee5ef000)
libm17n-flt.so.0 => /usr/lib/libm17n-flt.so.0 (0x00007f2eee3e4000)
libm17n-core.so.0 => /usr/lib/libm17n-core.so.0 (0x00007f2eee1b7000)
libgnutls.so.26 => /usr/local/lib/libgnutls.so.26 (0x00007f2eedf0b000)
libc.so.6 => /lib/libc.so.6 (0x00007f2eedb87000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f2eed975000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007f2eed772000)
libXi.so.6 => /usr/lib/libXi.so.6 (0x00007f2eed561000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007f2eed358000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00007f2eed14e000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x00007f2eecf4a000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007f2eecd47000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f2eecb41000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f2eec93c000)
libpcre.so.3 => /lib/libpcre.so.3 (0x00007f2eec70e000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00007f2eec4f4000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x00007f2eec29b000)
libdirectfb-1.2.so.0 => /usr/lib/libdirectfb-1.2.so.0 (0x00007f2eec017000)
libfusion-1.2.so.0 => /usr/lib/libfusion-1.2.so.0 (0x00007f2eebe0d000)
libdirect-1.2.so.0 => /usr/lib/libdirect-1.2.so.0 (0x00007f2eebbf4000)
libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0
(0x00007f2eeb9ef000)
libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x00007f2eeb7e6000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f2eeb5ca000)
libexpat.so.1 => /lib/libexpat.so.1 (0x00007f2eeb3a0000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2ef412a000)
libuuid.so.1 => /lib/libuuid.so.1 (0x00007f2eeb19b000)
libgsf-1.so.114 => /usr/lib/libgsf-1.so.114 (0x00007f2eeaf5b000)
libcroco-0.6.so.3 => /usr/lib/libcroco-0.6.so.3 (0x00007f2eead22000)
libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0x00007f2eeaab3000)
libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x00007f2eea891000)
libthai.so.0 => /usr/lib/libthai.so.0 (0x00007f2eea688000)
libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00007f2eea476000)
libgcrypt.so.11 => /lib/libgcrypt.so.11 (0x00007f2eea1fe000)
libgpg-error.so.0 => /lib/libgpg-error.so.0 (0x00007f2ee9ffa000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f2ee9df5000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f2ee9bef000)
libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00007f2ee99dd000)
libdatrie.so.1 => /usr/lib/libdatrie.so.1 (0x00007f2ee97d7000)
16:35:09 retriever emacs $
On 1/8/12, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Before starting Emacs: `free' shows 2gb in use.
>
> FWIW, "free" is not a very good tool to track the memory use of
> a specific process. Better check the VSZ and RSS of the process itself
> (and note that RSS can stay stable even in the presence of a leak,
> so VSZ is important).
>
>> Start Emacs 24 -- with just emacspeak loaded -- no immediate
>> signs of a leak -- `free' shows abut 6gb in use -- which does
>> seem a lot.
>
> What is Emacs's RSS and/or VSZ at startup?
>
>> M-x shell in that emacs
>> and wait for a couple of minutes.
>
>> Running `free' on a separate terminal shows that all 12GB of
>> memory in use -- emacs RSS is at 10GB.
>
>> If you dont kill the runnning emacs-24 at that point, it brings
>> the workstation to its knees and the machine stops responding and
>> needs to be rebooted.
>
> So you're saying that "emacs -Q" plus emacspeak plus "M-x shell" results
> on this machine in a process hat keeps growing even if you leave
> it alone?
> Could you run it under GDB (from the `emacs/src' directory) and
> interrupt the process (with C-z) every once in a while to try and see
> what it's doing?
>
>
> Stefan
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Memory Leak was: Re: Update on the Emacs release schedule? 8 messages
2012-01-08 14:23 ` Stefan Monnier
2012-01-18 0:39 ` T.V. Raman
@ 2012-01-25 19:36 ` T.V. Raman
1 sibling, 0 replies; 5+ messages in thread
From: T.V. Raman @ 2012-01-25 19:36 UTC (permalink / raw)
To: Stefan Monnier, emacs-devel
Hi Stephane,
I just installed the emacs 23.4 prebuild on the workstation that
shows the memory leak with emacs-24 from git, and am happy to
report there is no leak.
On 1/8/12, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Before starting Emacs: `free' shows 2gb in use.
>
> FWIW, "free" is not a very good tool to track the memory use of
> a specific process. Better check the VSZ and RSS of the process itself
> (and note that RSS can stay stable even in the presence of a leak,
> so VSZ is important).
>
>> Start Emacs 24 -- with just emacspeak loaded -- no immediate
>> signs of a leak -- `free' shows abut 6gb in use -- which does
>> seem a lot.
>
> What is Emacs's RSS and/or VSZ at startup?
>
>> M-x shell in that emacs
>> and wait for a couple of minutes.
>
>> Running `free' on a separate terminal shows that all 12GB of
>> memory in use -- emacs RSS is at 10GB.
>
>> If you dont kill the runnning emacs-24 at that point, it brings
>> the workstation to its knees and the machine stops responding and
>> needs to be rebooted.
>
> So you're saying that "emacs -Q" plus emacspeak plus "M-x shell" results
> on this machine in a process hat keeps growing even if you leave
> it alone?
> Could you run it under GDB (from the `emacs/src' directory) and
> interrupt the process (with C-z) every once in a while to try and see
> what it's doing?
>
>
> Stefan
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Memory Leak was: Re: Update on the Emacs release schedule? 8 messages
2012-01-08 3:28 Memory Leak was: Re: Update on the Emacs release schedule? 8 messages T. V. Raman
2012-01-08 14:23 ` Stefan Monnier
@ 2012-01-25 14:52 ` Nix
1 sibling, 0 replies; 5+ messages in thread
From: Nix @ 2012-01-25 14:52 UTC (permalink / raw)
To: tv.raman.tv; +Cc: emacs-devel
On 8 Jan 2012, T. V. Raman outgrape:
> Before starting Emacs: `free' shows 2gb in use.
An aside: the memory-in-use numbers from free are essentially
meaningless.
ps -o rss,vsz -C emacs
from a shell buffer is what you probably want.
(er, assuming that you can *get* a shell buffer without bringing Emacs
to its knees).
--
NULL && (void)
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-01-25 19:36 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-08 3:28 Memory Leak was: Re: Update on the Emacs release schedule? 8 messages T. V. Raman
2012-01-08 14:23 ` Stefan Monnier
2012-01-18 0:39 ` T.V. Raman
2012-01-25 19:36 ` T.V. Raman
2012-01-25 14:52 ` Nix
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).