From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id C2E441F597; Thu, 26 Jul 2018 06:21:50 +0000 (UTC) Date: Thu, 26 Jul 2018 06:21:50 +0000 From: Eric Wong To: Sam Saffron Cc: ruby-talk@ruby-lang.org, mwrap-public@80x24.org Subject: Re: [ANN] mwrap 2.0.0 mwrap - LD_PRELOAD malloc wrapper for Ruby Message-ID: <20180726062150.GA7047@dcvr> References: <20180720092516.GA23759@dcvr> <20180720093416.GA27657@dcvr> <20180726024601.ievg7jdr7blgtff6@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: Sam Saffron 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.