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