From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dima Kogan Newsgroups: gmane.emacs.devel Subject: Re: Debugging emacs memory management Date: Sun, 20 Sep 2015 15:01:01 -0700 Message-ID: <87vbb492ea.fsf@secretsauce.net> References: <87zj8l3r32.fsf@secretsauce.net> <87vbbbxz2e.fsf@secretsauce.net> <55F998C8.4080203@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442786499 25392 80.91.229.3 (20 Sep 2015 22:01:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Sep 2015 22:01:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 21 00:01:26 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zdmfj-0004eu-J0 for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 00:01:23 +0200 Original-Received: from localhost ([::1]:53900 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zdmfi-0007xN-Tg for ged-emacs-devel@m.gmane.org; Sun, 20 Sep 2015 18:01:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdmfV-0007x9-Bt for emacs-devel@gnu.org; Sun, 20 Sep 2015 18:01:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZdmfS-0004Hs-19 for emacs-devel@gnu.org; Sun, 20 Sep 2015 18:01:09 -0400 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]:48472) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdmfR-0004AP-O8 for emacs-devel@gnu.org; Sun, 20 Sep 2015 18:01:05 -0400 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id BF15C208CB for ; Sun, 20 Sep 2015 18:01:02 -0400 (EDT) Original-Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 20 Sep 2015 18:01:02 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=secretsauce.net; h=cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=3Qa03 YTDmgUHYtoRoH7MzbVPg44=; b=Hbz8+y9lLxVZvfzGcDe5hoHZG34ISEtACIwW5 kpsxQUl9U4aSIT/psw1q96vzFPQH0AHH77icjHytDGFmVqRHWMzJ7Lp0Aza36J+a tzhCy1lExiy8Gu0PClH8PAYLt5hLX/Ei8UbQq8pY/XwvH7cGtSVpOL5m5j7tqAoR mkyMLA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=3Qa03YTDmgUHYtoRoH7MzbVPg44=; b=b0yVa jq49ARBH4lTmcT3LRsnSJZVcRVKb6bjW2g/CkWI5Fhqvze91DJ9My488XCzFLWb2 qAHCo8TPhvpRuqSOGk0q7wmn04+k4AhZP5Ziv4sGrYK5Lw9yEfgJh2u3+DJx4UCo fdECaQ7HLF1bR+6fS4NS52Dgfg396kolPCO7Ek= X-Sasl-enc: eBW/cvVoSN86lTxFLkzGHHVt0zu2MbAy2x6qXfYPf+aT 1442786462 Original-Received: from shorty.local (50-1-153-216.dsl.dynamic.fusionbroadband.com [50.1.153.216]) by mail.messagingengine.com (Postfix) with ESMTPA id 69A4EC00018; Sun, 20 Sep 2015 18:01:02 -0400 (EDT) Original-Received: from ip6-localhost ([::1] helo=shorty) by shorty.local with esmtp (Exim 4.84) (envelope-from ) id 1ZdmfN-00007z-6B; Sun, 20 Sep 2015 15:01:01 -0700 In-reply-to: <55F998C8.4080203@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.25 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190157 Archived-At: Paul Eggert 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?