[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fixing memory leaks before the pretest (was: Update on the Emacs rel
From: |
YAMAMOTO Mitsuharu |
Subject: |
Re: fixing memory leaks before the pretest (was: Update on the Emacs release schedule?) |
Date: |
Sun, 08 Jan 2012 11:39:27 +0900 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) |
>>>>> On Sat, 7 Jan 2012 17:57:38 +0100, Carsten Mattner <address@hidden> said:
> 2012/1/7 Ted Zlatanov <address@hidden>:
>> On Sat, 07 Jan 2012 15:10:38 +0800 Chong Yidong <address@hidden>
>> 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
address@hidden
- Re: Update on the Emacs release schedule?, (continued)
fixing memory leaks before the pretest (was: Update on the Emacs release schedule?), Ted Zlatanov, 2012/01/07