From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id CA904431FAF for ; Sun, 16 Dec 2012 14:15:04 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9GRrVtXbZTi for ; Sun, 16 Dec 2012 14:15:03 -0800 (PST) Received: from tesseract.cs.unb.ca (tesseract.cs.unb.ca [131.202.240.238]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 6FEF3431FAE for ; Sun, 16 Dec 2012 14:15:03 -0800 (PST) Received: from fctnnbsc30w-142167090129.dhcp-dynamic.fibreop.nb.bellaliant.net ([142.167.90.129] helo=zancas.localnet) by tesseract.cs.unb.ca with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TkMUA-00081I-8E; Sun, 16 Dec 2012 18:15:02 -0400 Received: from bremner by zancas.localnet with local (Exim 4.80) (envelope-from ) id 1TkMU4-0005VX-Py; Sun, 16 Dec 2012 18:14:56 -0400 From: David Bremner To: notmuch@notmuchmail.org Subject: Re: [PATCH 4/4] perf-test: add memory leak test for dump restore In-Reply-To: <1355682208-13729-5-git-send-email-david@tethera.net> References: <1355682208-13729-1-git-send-email-david@tethera.net> <1355682208-13729-5-git-send-email-david@tethera.net> User-Agent: Notmuch/0.14+163~g11a220a (http://notmuchmail.org) Emacs/24.2.1 (x86_64-pc-linux-gnu) Date: Sun, 16 Dec 2012 18:14:56 -0400 Message-ID: <87obht4pb3.fsf@zancas.localnet> MIME-Version: 1.0 Content-Type: text/plain X-Spam_bar: - X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 22:15:05 -0000 david@tethera.net writes: > + > +memory_run 'load nmbug tags' 'notmuch restore --accumulate --input=corpus.tags/nmbug.sup-dump' > +memory_run 'dump *' 'notmuch dump --output=tags.sup' > +memory_run 'restore *' 'notmuch restore --input=tags.sup' > +memory_run 'dump --format=batch-tag *' 'notmuch dump --format=batch-tag --output=tags.bt' > +memory_run 'restore --format=batch-tag *' 'notmuch restore --format=batch-tag --input=tags.bt' > + We were talking on IRC about how/if valgrind would cope with talloc, and the possibility that chunks of memory are still reachable by talloc, but not by user code. Currently the talloc context "local" in main() is (slightly perversely) only freed in the case of "return 1", so all the memory allocated by talloc on that contex is shown as leaked: 3,005,500 (93 direct, 3,005,407 indirect) bytes in 1 blocks are definitely lost in loss record 553 of 553 at 0x4C2A26B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x55F14C7: talloc_strndup (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.0.7) by 0x4115E8: parse_sup_line (notmuch-restore.c:90) by 0x411AD4: notmuch_restore_command (notmuch-restore.c:209) by 0x40B2A4: main (notmuch.c:294) Although this is probably a bug in main(), it does point valgrind to the right culprit. As our memory allocation is (alas) a mix of talloc, malloc, and g_malloc, we probably need both valgrind tests, and some way to toggle talloc memory debugging. ( http://talloc.samba.org/talloc/doc/html/group__talloc__debug.html ) d