On 07/13/2012 11:28 AM, Harald Leithner wrote:
> Hi Paul,
>
> do we have any updates on this?
Not much. The problem is very difficult to reproduce reliably. Valgrind
traces generated using the steps outlined by Harald Reindl below seem to
point in the direction of either glib's slice-allocator, or thread-races
in dbmail that I'm unable to explain.
>>> I'm observing decent memory leaks in all four dbmail daemons. In
>>> producton impad grows by about 300MB per day, others less since
>>> they're less utilized.
Any leakage in lmtp/pop3/timsieve should be *much* easier to debug and
fix since those are *not* threaded. If anyone is up to present me with
command sequences that lead to non-trivial leakage I'd be happy to look
into it.
>>>
>>> Anyone else observing this?
>>> Is there an easy way to figure out where the memory is leaking
>>> without interrupting the service?
No. You need to:
compile with debug-flags (-j) and without stripping the binaries
run the deamons using valgrind, i.e.
G_SLICE=always-malloc valgrind --leak-check=full
--log-file=/tmp/vg-lmtpd.log .../dbmail-lmtpd -D
keep it running for a while, stop the service (ctrl-c), study the logs.
Any indication in the logs of definite leakage (ignore possible or
indirect leakage) definitely needs to be fixed if it originates in the
dbmail code.
--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin
* Premium Hosting Services and Web Application Consultancy *
www.nfg.nl/i...@nfg.nl/+31.85.877.99.97
________________________________________________________________
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
