Hey,
So, bad news: having updated to the latest Bongo rev, my bongosmtpc
doesn't appear to be leaking memory at all. It started at 16Mb, it's
sitting at 24Mb now, I'll keep an eye on it.
It does seem that we need to have better memory allocation
instrumentation to figure out problems like these, though. I did a
compile with configure --enable-memmgrleakreporting, and there do seem
to be some exciting features that we're missing.
I got some output like:
MemMGR: free'd allocation free'd again by src/libs/bongoutil/array.c
[59]; originally free'd by src/libs/bongoutil/array.c [59].
MemMGR: free'd allocation free'd again by src/libs/bongoutil/array.c
[95]; originally free'd by src/libs/bongoutil/array.c [95].
(after bongo-config install; slightly - well, no, mostly - useless, but
useful to know)
And then shutting down bongo agents, stuff like:
MemMGR: Leak report for "128 Bytes"
6 octets for "src/libs/nmap/bongoagent.c" on 161
10 octets for "src/libs/nmap/bongoagent.c" on 161
10 octets for "src/libs/nmap/bongoagent.c" on 161
77 octets for "src/libs/nmap/nmap.c" on 1279
51 octets for "src/libs/nmap/nmap.c" on 1279
So it's giving a leak report for each memory pool. And this looks a bit
more useful:
bongoagent.c:161 - some global variable not being free'd on shutdown
nmap.c:1279 - probably someone failing to clean up after
NMAPReadConfigFile(), unsurprisingly.
Perhaps we should try to crack down on some of this stuff. It would be
nice to be absolutely leak-free; it's not necessarily more correct
(e.g., I don't care about bongoagent.c:161, but I probably do care
nmap.c:1279 - or I will care in the future - and we may as well clean
them all up).
It would also be nice to have some way of testing this in an automatic
fashion, but maybe that would need to come later...
Cheers,
Alex.
_______________________________________________
Bongo-devel mailing list
[email protected]
https://mail.gna.org/listinfo/bongo-devel
