[PATCH 4/4] perf-test: add memory leak test for dump restore

[David Bremner]

david at 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

[PATCH 4/4] perf-test: add memory leak test for dump restore

[da...@tethera.net]

From: David Bremner 

In id:87vcc2q5n2.fsf at nikula.org, Jani points out a memory leak in the
current version of the sup restore code. Among other things, this test
is intended to verify a fix for that leak.
---
 performance-test/M01-dump-restore |   15 +++
 1 file changed, 15 insertions(+)
 create mode 100755 performance-test/M01-dump-restore

diff --git a/performance-test/M01-dump-restore 
b/performance-test/M01-dump-restore
new file mode 100755
index 000..be5894a
--- /dev/null
+++ b/performance-test/M01-dump-restore
@@ -0,0 +1,15 @@
+#!/bin/bash
+
+test_description='dump and restore'
+
+. ./perf-test-lib.sh
+
+memory_start
+
+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'
+
+memory_done
-- 
1.7.10.4

[PATCH 4/4] perf-test: add memory leak test for dump restore

[david]

From: David Bremner brem...@debian.org

In id:87vcc2q5n2@nikula.org, Jani points out a memory leak in the
current version of the sup restore code. Among other things, this test
is intended to verify a fix for that leak.
---
 performance-test/M01-dump-restore |   15 +++
 1 file changed, 15 insertions(+)
 create mode 100755 performance-test/M01-dump-restore

diff --git a/performance-test/M01-dump-restore 
b/performance-test/M01-dump-restore
new file mode 100755
index 000..be5894a
--- /dev/null
+++ b/performance-test/M01-dump-restore
@@ -0,0 +1,15 @@
+#!/bin/bash
+
+test_description='dump and restore'
+
+. ./perf-test-lib.sh
+
+memory_start
+
+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'
+
+memory_done
-- 
1.7.10.4

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 4/4] perf-test: add memory leak test for dump restore

[David Bremner]

da...@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


___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch