From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Markus Triska Newsgroups: gmane.emacs.devel Subject: Re: Debugging emacs memory management Date: Thu, 17 Sep 2015 00:03:11 +0200 Message-ID: <87lhc6qaxs.fsf@morgenrot.metalevel.at> References: <87zj8l3r32.fsf@secretsauce.net> <87vbbbxz2e.fsf@secretsauce.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442441427 18181 80.91.229.3 (16 Sep 2015 22:10:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Sep 2015 22:10:27 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 17 00:10:19 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 1ZcKu9-0004GT-Av for ged-emacs-devel@m.gmane.org; Thu, 17 Sep 2015 00:10:17 +0200 Original-Received: from localhost ([::1]:53971 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcKu9-0003Av-0K for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 18:10:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcKu5-0003An-OD for emacs-devel@gnu.org; Wed, 16 Sep 2015 18:10:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcKu1-0001Y3-N8 for emacs-devel@gnu.org; Wed, 16 Sep 2015 18:10:13 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:44295) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcKu1-0001XW-H0 for emacs-devel@gnu.org; Wed, 16 Sep 2015 18:10:09 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZcKtw-00043Z-Sf for emacs-devel@gnu.org; Thu, 17 Sep 2015 00:10:04 +0200 Original-Received: from 78.47.52.107 ([78.47.52.107]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Sep 2015 00:10:04 +0200 Original-Received: from triska by 78.47.52.107 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Sep 2015 00:10:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 28 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78.47.52.107 Cancel-Lock: sha1:1hbNoxy/GbrjNJFYD9ItYkPx46E= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:190039 Archived-At: Hi Dima, Dima Kogan writes: > Yesterday I FINALLY found a sequence of steps to reliably reproduce the > issue, so debugging became possible. Sequence: Many thanks for looking into this! > However another observation is that even with an empty init.el this > sequence still leaks memory, albeit more slowly. It looks like a bug > also. I have some malloc tracing set up with backtrace reporting, but > there're a LOT of allocations, and I haven't figured out a good way to > sort through them yet. I have previously also found memory leaks in connection with emacsclient. Please see #1504 for a test case: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1504 A major problem with such memory management issues is that they prevent you from running longer automated test cases to track down other, often unrelated, issues that sometimes take a long time to reproduce. Therefore, thank you for your work in this direction! All the best, Markus