From: Dima Kogan <lists@dima.secretsauce.net>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: emacs-devel@gnu.org
Subject: Re: Debugging emacs memory management
Date: Sun, 20 Sep 2015 15:01:01 -0700 [thread overview]
Message-ID: <87vbb492ea.fsf@secretsauce.net> (raw)
In-Reply-To: <55F998C8.4080203@cs.ucla.edu>
Paul Eggert <eggert@cs.ucla.edu> writes:
> Thanks for all that work. I installed the patch after tweaking its comment and
> ChangeLog entry.
Thank you Paul. I'm continuint to dig. I found out that repeatedly
creating/destroying the first frame is far more leaky than a non-first
frame:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21509
This should be fixed, but in my use I always have multiple frames open,
so this isn't biting me. Even with a frame open, each new frame
create/destroy cycle leaks about 15kB. Digging into this, the leaky
malloc() path is:
emacs-snapshot- 28044 [000] 587944.079120: probe_libc:malloc: (7fa38bffc020) bytes=0x1000
7c020 malloc (/lib/x86_64-linux-gnu/libc-2.19.so)
14518f allocate_vectorlike.part.19 (/usr/bin/emacs-snapshot-lucid)
145ead allocate_vector (/usr/bin/emacs-snapshot-lucid)
a427c make_sub_char_table (/usr/bin/emacs-snapshot-lucid)
a4f1a sub_char_table_set_range (/usr/bin/emacs-snapshot-lucid)
a4f34 sub_char_table_set_range (/usr/bin/emacs-snapshot-lucid)
a69a8 char_table_set_range (/usr/bin/emacs-snapshot-lucid)
a6b40 Fset_char_table_range (/usr/bin/emacs-snapshot-lucid)
1c838b Fset_fontset_font (/usr/bin/emacs-snapshot-lucid)
1c9dfc fontset_from_font (/usr/bin/emacs-snapshot-lucid)
c9e50 x_new_font (/usr/bin/emacs-snapshot-lucid)
2534e x_set_font (/usr/bin/emacs-snapshot-lucid)
23e66 x_set_frame_parameters (/usr/bin/emacs-snapshot-lucid)
26ab5 x_default_parameter (/usr/bin/emacs-snapshot-lucid)
d03ba x_default_font_parameter (/usr/bin/emacs-snapshot-lucid)
d7f98 Fx_create_frame (/usr/bin/emacs-snapshot-lucid)
15f933 Ffuncall (/usr/bin/emacs-snapshot-lucid)
195823 exec_byte_code (/usr/bin/emacs-snapshot-lucid)
15f350 funcall_lambda (/usr/bin/emacs-snapshot-lucid)
15f72b Ffuncall (/usr/bin/emacs-snapshot-lucid)
195823 exec_byte_code (/usr/bin/emacs-snapshot-lucid)
15f72b Ffuncall (/usr/bin/emacs-snapshot-lucid)
160d13 Fapply (/usr/bin/emacs-snapshot-lucid)
15f831 Ffuncall (/usr/bin/emacs-snapshot-lucid)
195823 exec_byte_code (/usr/bin/emacs-snapshot-lucid)
15f72b Ffuncall (/usr/bin/emacs-snapshot-lucid)
195823 exec_byte_code (/usr/bin/emacs-snapshot-lucid)
15f72b Ffuncall (/usr/bin/emacs-snapshot-lucid)
195823 exec_byte_code (/usr/bin/emacs-snapshot-lucid)
15f72b Ffuncall (/usr/bin/emacs-snapshot-lucid)
195823 exec_byte_code (/usr/bin/emacs-snapshot-lucid)
15f72b Ffuncall (/usr/bin/emacs-snapshot-lucid)
195823 exec_byte_code (/usr/bin/emacs-snapshot-lucid)
15f72b Ffuncall (/usr/bin/emacs-snapshot-lucid)
160bb0 Fapply (/usr/bin/emacs-snapshot-lucid)
160d8a apply1 (/usr/bin/emacs-snapshot-lucid)
15df4a internal_condition_case_1 (/usr/bin/emacs-snapshot-lucid)
1992e0 read_process_output (/usr/bin/emacs-snapshot-lucid)
1a0c6b wait_reading_process_output (/usr/bin/emacs-snapshot-lucid)
1ed86 sit_for (/usr/bin/emacs-snapshot-lucid)
f6b79 read_char (/usr/bin/emacs-snapshot-lucid)
f7534 read_key_sequence.constprop.35 (/usr/bin/emacs-snapshot-lucid)
f9200 command_loop_1 (/usr/bin/emacs-snapshot-lucid)
15de36 internal_condition_case (/usr/bin/emacs-snapshot-lucid)
ea74c command_loop_2 (/usr/bin/emacs-snapshot-lucid)
15dd2a internal_catch (/usr/bin/emacs-snapshot-lucid)
ea709 command_loop (/usr/bin/emacs-snapshot-lucid)
ef133 recursive_edit_1 (/usr/bin/emacs-snapshot-lucid)
ef4ab Frecursive_edit (/usr/bin/emacs-snapshot-lucid)
148c6 main (/usr/bin/emacs-snapshot-lucid)
21b45 __libc_start_main (/lib/x86_64-linux-gnu/libc-2.19.so)
I'll do a writeup about how exactly to get that later. In the meantime,
does this speak to anybody? It looks like we're creating a new Lisp
object, so I guess the gc is supposed to clean it out. I don't (yet)
know the details about how references are managed, but maybe they're not
handled properly here. Is the recursive call to
sub_char_table_set_range() causing issues?
next prev parent reply other threads:[~2015-09-20 22:01 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-11 6:01 Debugging emacs memory management Dima Kogan
2015-02-11 15:05 ` Stefan Monnier
2015-02-15 20:28 ` Dima Kogan
2015-02-15 20:47 ` Eli Zaretskii
2015-02-16 1:39 ` Stefan Monnier
2015-02-17 7:59 ` Dima Kogan
2015-02-17 15:59 ` Eli Zaretskii
2015-02-18 0:07 ` Stefan Monnier
2015-02-11 19:07 ` Florian Weimer
2015-09-15 19:27 ` Dima Kogan
2015-09-16 16:28 ` Paul Eggert
2015-09-20 22:01 ` Dima Kogan [this message]
2015-09-21 6:46 ` Eli Zaretskii
2015-09-21 8:54 ` Dima Kogan
2015-09-21 10:00 ` Eli Zaretskii
2015-09-21 10:21 ` Eli Zaretskii
2015-09-22 21:33 ` Dima Kogan
2015-09-23 6:35 ` Eli Zaretskii
2015-09-23 6:37 ` Dima Kogan
2015-09-23 7:16 ` Eli Zaretskii
2015-10-05 7:21 ` Dima Kogan
2015-10-05 7:55 ` Eli Zaretskii
2015-10-05 8:24 ` Dima Kogan
2015-10-05 8:33 ` Eli Zaretskii
2015-10-05 8:43 ` Eli Zaretskii
2015-10-05 9:24 ` Dima Kogan
2015-10-05 9:49 ` Dima Kogan
2015-10-05 9:58 ` Andreas Schwab
2015-10-05 10:02 ` Dima Kogan
2015-10-05 10:47 ` Eli Zaretskii
2015-10-05 18:19 ` Dima Kogan
2015-10-05 18:24 ` Eli Zaretskii
2015-10-05 23:21 ` Dima Kogan
2015-10-06 2:41 ` Eli Zaretskii
2015-10-08 21:51 ` Dima Kogan
2015-09-16 16:34 ` Davis Herring
2015-09-16 22:03 ` Markus Triska
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vbb492ea.fsf@secretsauce.net \
--to=lists@dima.secretsauce.net \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.