Paul J Stevens wrote: >> ==1631== 71,603,456 bytes in 288,752 blocks are still reachable in loss >> record 26 of 26 > > This could be a side effect of the slab allocator. Use > G_DEBUG=always_malloc valgrind ... to circumvent the glib default > allocator.
Tested with 'export G_DEBUG=always_malloc' yielding nearly identical results (71,604,456 bytes this time). New logs at http://rabbit.us/pool/misc/dbmail_bug584_memcheck_svn2574_always_malloc.tar.bz2 > This URL has some interesting points > http://www.tinymail.org/trac/tinymail/wiki/MemoryStats Erm, being a n00b and all, wouldn't this affect both imap daemons involved in the test? In my case only 'host2' leaks, 'host1' stabilizing at about 40M VSZ. Peter _______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
