From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
To: Carsten Mattner <carstenmattner@googlemail.com>
Cc: emacs-devel@gnu.org
Subject: Re: fixing memory leaks before the pretest (was: Update on the Emacs release schedule?)
Date: Sun, 08 Jan 2012 11:39:27 +0900 [thread overview]
Message-ID: <wl62gmc3z4.wl%mituharu@math.s.chiba-u.ac.jp> (raw)
In-Reply-To: <CACY+HvrbmLmGcijf=tuAXwr86zguyDAkf3RNtvQSSYHUD6dh+w@mail.gmail.com>
>>>>> On Sat, 7 Jan 2012 17:57:38 +0100, Carsten Mattner <carstenmattner@googlemail.com> said:
> 2012/1/7 Ted Zlatanov <tzz@lifelogs.com>:
>> On Sat, 07 Jan 2012 15:10:38 +0800 Chong Yidong <cyd@gnu.org>
>> wrote:
>>
CY> As for the code, there are still a number of issues that need more
CY> attention, most prominently the mysterious memory leak(s) that may
CY> or may not involve Gnus and/or GnuTLS and/or Mac OS X.
>>
>> I am seeing memory growth on GNU/Linux with Gnus and GnuTLS that I
>> don't see otherwise without Gnus, so it's faintly possible GnuTLS
>> is not the determining factor. I have gone over the gnutls.c code
>> and don't see where the GnuTLS glue could be leaking. If it is,
>> I'll need a tool like Valgrind to help me, and last time I tried
>> that, the reports were not helpful to me (too much data, not enough
>> leading back to GnuTLS). I spent 2 days on this last week and
>> meant to bring it up this week, actually (the discussion about
>> GnuTLS on W32 sort of distracted me :)
>>
>> Maybe someone who actually knows how to use Valgrind could help me
>> or try to find the leaks themselves?
> Tried LLVM AddressSanitizer? It's supposed to be a low-impact
> compile flag. http://clang.llvm.org/docs/AddressSanitizer.html
> From the documentation I'm not sure it's useful for finding leaks.
I suggested a possible way to analyze heap usage on Mac OS X only
using some commands that bundled with the standard developer tools:
http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00552.html .
Has anybody who are seeing memory issues on Mac OS X tried this? At
least we can make sure whether there are some bogus root references or
freed memory is not returned to the system.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
prev parent reply other threads:[~2012-01-08 2:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-07 4:47 Update on the Emacs release schedule? Lars Magne Ingebrigtsen
2012-01-07 7:10 ` Chong Yidong
2012-01-07 11:02 ` Carsten Mattner
2012-01-07 13:45 ` Ted Zlatanov
2012-01-07 17:02 ` Carsten Mattner
2012-01-07 18:11 ` Stefan Monnier
2012-01-07 18:32 ` Carsten Mattner
2012-01-07 20:13 ` Jan Djärv
2012-01-08 13:54 ` Stefan Monnier
2012-01-07 13:44 ` fixing memory leaks before the pretest (was: Update on the Emacs release schedule?) Ted Zlatanov
2012-01-07 15:49 ` fixing memory leaks before the pretest Chong Yidong
2012-01-10 0:59 ` Ted Zlatanov
2012-01-07 16:57 ` fixing memory leaks before the pretest (was: Update on the Emacs release schedule?) Carsten Mattner
2012-01-08 2:39 ` YAMAMOTO Mitsuharu [this message]
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=wl62gmc3z4.wl%mituharu@math.s.chiba-u.ac.jp \
--to=mituharu@math.s.chiba-u.ac.jp \
--cc=carstenmattner@googlemail.com \
--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 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).