unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: emacs user <user.emacs@gmail.com>
To: 10277@debbugs.gnu.org
Subject: bug#10277: 24.0.91; memory leak when using vm
Date: Tue, 13 Dec 2011 22:12:36 +0200	[thread overview]
Message-ID: <CAK16+CfXoLJ44hvKZyJdm58iBFfHXHDtUHbxhiMK2CMpNwm5VQ@mail.gmail.com> (raw)
In-Reply-To: <CAK16+CdcDv1RdnmsqjcFRCDZwZU6ywg6DKvw42nBN3tKmTMA0g@mail.gmail.com>

here is a new memory report, perhaps this helps?  emacs size is about
300Mb at this point.

Garbage collection stats:
((393819 . 210587) (67307 . 146) (71862 . 15273) 4244548 1877886 (713
. 725) (1033 . 796) (227352 . 74712))

 =>	6301104+3369392 bytes in cons cells
	3230736+7008 bytes in symbols
	2874480+610920 bytes in markers
	11408+11600 bytes in floats
	57848+44576 bytes in intervals
	7275264+2390784 bytes in string headers
	4244548 bytes of string chars
	4244548 bytes of vector slots

Total bytes in lisp objects: 32307554 (live 25873274, dead 6434280)

Buffer ralloc memory usage:
61 buffers
63670 bytes total (32924 in gaps)
      Size	Gap	Name

     20348	2000	 *w3m cache*
      4962	1783	.emacs.d
      2186	987	 *srecode-map-tmp*
      2186	1814	 *code-converting-work*
       567	1571	*Buffer Details*
       191	2000	*scratch*
       152	1876	 *Marked Files*
       125	1921	*Messages*
        54	1987	 *extract address components*
        33	2008	 *canonical address*
        13	7	 *Deletions*
        13	2042	 *Echo Area 0*
        10	5818	 *code-conversion-work*
         0	2021	 *Minibuf-1*
         0	20	 *vm-nonexistent-summary*
         0	20	 *Minibuf-0*
         0	2051	 *Echo Area 1*
         0	20	 *subst-char-in-string*
         0	20	 *vmpc-cleanup*
         0	20	 *w3m-work*
         0	20	 *w3m-work*<3>
         0	20	 *w3m-work*<5>
         0	20	 *w3m-work*<7>
         0	20	 *w3m-work*<9>
         0	20	 *w3m-work*<11>
         0	20	 *w3m-work*<13>
         0	20	 *w3m-work*<15>
         0	2044	 *split*
         0	20	 *w3m-work*<17>
         0	20	 *w3m-work*<19>
         0	20	 *w3m-work*<21>
         0	20	 *w3m-work*<23>
         0	20	 *w3m-work*<25>
         0	20	 *w3m-work*<27>
         0	20	 *w3m-work*<29>
         0	20	 *w3m-work*<31>
         0	20	 *w3m-work*<33>
         0	20	 *w3m-work*<35>
         0	20	 *w3m-work*<2>
         0	20	 *w3m-work*<6>
         0	20	 *w3m-work*<10>
         0	20	 *w3m-work*<14>
         0	20	 *w3m-work*<18>
         0	20	 *w3m-work*<22>
         0	20	 *w3m-work*<26>
         0	20	 *w3m-work*<30>
         0	20	 *w3m-work*<34>
         0	20	 *w3m-work*<37>
         0	20	 *w3m-work*<4>
         0	20	 *w3m-work*<12>
         0	20	 *w3m-work*<20>
         0	20	 *w3m-work*<28>
         0	20	 *w3m-work*<36>
         0	20	 *w3m-work*<39>
         0	20	 *w3m-work*<41>
         0	20	 *w3m-work*<43>
         0	20	 *w3m-work*<45>
         0	20	 *w3m-work*<47>
         0	20	 *w3m-work*<49>
         0	20	 *w3m-work*<51>
         0	20	 *w3m-work*<53>

On Sun, Dec 11, 2011 at 11:17 PM, emacs user <user.emacs@gmail.com> wrote:
> In GNU Emacs 24.0.91.1 (x86_64-apple-darwin11.2.0, NS apple-appkit-1138.23)
>  of 2011-11-25 on MacBook-Air.local
> Windowing system distributor `Apple', version 10.3.1138
> configured using `configure  '--with-ns''
>
> when using vm, emacs grows in size every time I read my inbox, and
> eventually crashes.  garbage-collect has no effect.  memory-usage.el
> gives the output below, I would be grateful for any hints on how to
> identify the problem...
>
> [at the time of this report, emacs grew to about 200mb (using activity
> monitor on the mac).  it's initial size was about 30mb. ]
>
> \Garbage collection stats:
> ((470940 . 228143) (128755 . 1) (348632 . 1073) 9089641 3274519 (123 .
> 1083) (4119 . 14324) (691547 . 38503))
>
>  =>     7535040+3650288 bytes in cons cells
>        6180240+48 bytes in symbols
>        13945280+42920 bytes in markers
>        1968+17328 bytes in floats
>        230664+802144 bytes in intervals
>        22129504+1232096 bytes in string headers
>        9089641 bytes of string chars
>        9089641 bytes of vector slots
>
> Total bytes in lisp objects: 68131680 (live 62386856, dead 5744824)
>
> Buffer ralloc memory usage:
> 10 buffers
> 10404 bytes total (9887 in gaps)
>      Size      Gap     Name
>
>       568      1572    *Buffer Details*
>        20      2045     *Echo Area 1*
>        17      3        *Custom-Work*
>         5      2020     *code-conversion-work*
>         0      20      *scratch*
>         0      2037     *Minibuf-1*
>         0      20       *vm-nonexistent-summary*
>         0      20       *Minibuf-0*
>         0      2037     *Echo Area 0*
>         0      20       *subst-char-in-string*





  reply	other threads:[~2011-12-13 20:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-11 21:17 bug#10277: 24.0.91; memory leak when using vm emacs user
2011-12-13 20:12 ` emacs user [this message]
2019-09-20 23:19 ` Stefan Kangas
2019-10-30 19:52   ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK16+CfXoLJ44hvKZyJdm58iBFfHXHDtUHbxhiMK2CMpNwm5VQ@mail.gmail.com \
    --to=user.emacs@gmail.com \
    --cc=10277@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).