[syslog-ng] Possible memleak in 3.3 HEAD

[Balazs Scheidler]

On Wed, 2011-10-05 at 01:44 +0200, Jakub Jankowski wrote:
> On Mon, 3 Oct 2011 14:34:13 +0200 (CEST), Jakub Jankowski wrote:
> > 
> > As strange as it was, it seems really fixed with git HEAD. Using dist 
> > tarball Gergely provided (thanks again), I've built 
> > 70fa96f33c89ce2bb10d10aaa7ba0492764a441c and ran my tests. Results are 
> > comforting:
> > 
> > $ grep -A 6 'LEAK SUMMARY'
> > s3.3.1-70fa96f33c89ce2bb10d10aaa7ba0492764a441c-const.log ==28094== LEAK
> > SUMMARY: ==28094==    definitely lost: 101 bytes in 2 blocks
> > ==28094==    indirectly lost: 1,010 bytes in 21 blocks
> > ==28094==      possibly lost: 12,919 bytes in 106 blocks
> > ==28094==    still reachable: 76,628 bytes in 3,275 blocks
> > ==28094==         suppressed: 0 bytes in 0 blocks
> > ==28094==
> > $ grep -A 6 'LEAK SUMMARY'
> > s3.3.1-70fa96f33c89ce2bb10d10aaa7ba0492764a441c-random.log ==30031== LEAK
> > SUMMARY: ==30031==    definitely lost: 101 bytes in 2 blocks
> > ==30031==    indirectly lost: 1,010 bytes in 21 blocks
> > ==30031==      possibly lost: 12,919 bytes in 106 blocks
> > ==30031==    still reachable: 76,628 bytes in 3,275 blocks
> > ==30031==         suppressed: 0 bytes in 0 blocks
> > ==30031==
> > $
> > 
> > It behaves the same no matter what files it creates. I'll soon see how 
> > it's doing on production systems. Thanks for the fix and help.
> 
> I think I spoke too soon. :-/
> See attached cacti graph. This is basically an output of
> awk '/VmRSS:/ { $print $2*1024 }'  /proc/$(cat /var/run/syslog-ng.pid)/status
> on git head ("3.3.1" ATM). There must be something else going on; any hints
> on how to diagnose this?

It definitely seems to be a leak of some kind. If at all possible,
running it for some time under valgrind like you did previously would be
tremendous.

If that's not possible, even generating a core file and running:

strings core | sort | uniq -c

And try to guess what it could be would probably help to narrow this
down.

-- 
Bazsi