all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ted Zlatanov <tzz@lifelogs.com>
To: emacs-devel@gnu.org
Subject: Re: fixing memory leaks before the pretest
Date: Mon, 09 Jan 2012 19:59:22 -0500	[thread overview]
Message-ID: <87obucid91.fsf@lifelogs.com> (raw)
In-Reply-To: 87sjjrzf6a.fsf@gnu.org

On Sat, 07 Jan 2012 23:49:01 +0800 Chong Yidong <cyd@gnu.org> wrote: 

CY> Ted Zlatanov <tzz@lifelogs.com> writes:
>> 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.

CY> Do you have a test case for, e.g. creating and closing a few thousand
CY> GnuTLS connections to a localhost running apache with https and seeing
CY> if there is any memory impact?  That would be the first thing I would
CY> try, but I haven't had the time to look into this.

I did, to a Dovecot IMAP server:

#+begin_src lisp
(require 'gnutls)
(setq gnutls-log-level 10)
(dotimes (n 10000)
  (setq buf (open-gnutls-stream "tls" "tls-buffer" "myserver" "imaps"))
  (delete-process buf))
#+end_src

It took a while, but throughout the memory usage remained consistently
at 331 MB virtual, 53 MB resident, 15 MB shared.  Once the loop ended
and Emacs calmed down, virtual was the same but resident dropped to 39
MB and shared was 4 MB.  By comparison a new Emacs without any GnuTLS
initialization is 320 MB virtual, 45 MB resident, and 14 MB shared.

Based on that, I don't think there are obvious GnuTLS leaks in the
connection open/close sequence.  There may be leaks in the packet
handling, though.  I tried:

#+begin_src lisp
(dotimes (n 10000)
  (setq buf (open-gnutls-stream "tls" "tls-buffer" "myserver" "imaps"))
  (process-send-string buf "hello there")
  (sit-for 1)
  (message (with-current-buffer (process-buffer buf) (buffer-string)))
  (delete-process buf))
#+end_src

and did not see a difference in the memory usage either (331/53/10).
The IMAP server's greetings definitely came through, so the test was
exercising the connection.  This does not necessarily mean there are no
leaks, but if they exist, they are probably not large or don't happen
with the first few packets exchanged.

I can look at this further... let me know what tests I should do.  I'd
like to prove there are leaks at all.

Thanks
Ted




  reply	other threads:[~2012-01-10  0:59 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 [this message]
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

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=87obucid91.fsf@lifelogs.com \
    --to=tzz@lifelogs.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 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.