mwrap user+dev discussion/patches/pulls/bugs/help
 help / color / Atom feed
From: Eric Wong <e@80x24.org>
To: Sam Saffron <sam.saffron@gmail.com>
Cc: ruby-talk@ruby-lang.org, mwrap-public@80x24.org
Subject: Re: [ANN] mwrap 2.0.0 mwrap - LD_PRELOAD malloc wrapper for Ruby
Date: Thu, 26 Jul 2018 06:21:50 +0000
Message-ID: <20180726062150.GA7047@dcvr> (raw)
In-Reply-To: <CAAtdryNv726Aq=Dy7re8PZjQj080ceG22UWe0LXDohRF0Woe2Q@mail.gmail.com>

Sam Saffron <sam.saffron@gmail.com> wrote:
> Yes, this patch looks right to me.

OK, I've just pushed it out to RubyGems.org as a prerelease:

    mwrap-2.0.0.4.gd1ea.gem

> Even if we don't have perfect fidelity here it will give absolute
> clarity on "leak" vs "fragmentation related bloat". Even though
> jemalloc tries hard to compensate for fragmentation bloat is still
> possible.

Just wondering, are you still on jemalloc 3.6.0 or one of the
newer versions?  I seem to remember 3.6.0 interacting badly with
cross-thread frees (from another project years ago); and mwrap
relies on call_rcu to free memory which is in another thread...

Maybe narenas:1 or even using MALLOC_ARENA_MAX=1 glibc malloc
might make it easier to discern a real leak from fragmentation.

In any case; one technique I've used in the past which never
required special debugging tools (aside from source access) was
to use a bisection search over the code path.  I disabled/skipped
over half the remaining code until the leak could no longer be
reproduced to narrow down where it did happen.

      reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-20  9:25 [PATCH] " Eric Wong
2018-07-20  9:34 ` [ANN] " Eric Wong
2018-07-26  1:36   ` Sam Saffron
2018-07-26  1:37     ` Sam Saffron
2018-07-26  2:46       ` Eric Wong
2018-07-26  5:02         ` Sam Saffron
2018-07-26  6:21           ` Eric Wong [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://80x24.org/mwrap/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180726062150.GA7047@dcvr \
    --to=e@80x24.org \
    --cc=mwrap-public@80x24.org \
    --cc=ruby-talk@ruby-lang.org \
    --cc=sam.saffron@gmail.com \
    /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

mwrap user+dev discussion/patches/pulls/bugs/help

Archives are clonable:
	git clone --mirror https://80x24.org/mwrap-public/0 mwrap-public/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 mwrap-public mwrap-public/ https://80x24.org/mwrap-public \
		mwrap-public@80x24.org
	public-inbox-index mwrap-public

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.lang.ruby.mwrap
	nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.mwrap

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git