On Fri, 2007-07-06 at 17:18 +1200, anthony lineham wrote:
I've noticed a small memory leak when syslog-ng handles a SIGHUP.
A bit of valgrind-ing gave me the following result for syslog-ng without any SIGHUPs 1,004 (652 direct, 352 indirect) bytes in 7 blocks are definitely lost in loss record 9 of 16 ==11308== at 0x402C9C0: calloc (in /opt/4/lib/valgrind/ppc32-linux/vgpreload_memcheck.so) ==11308== by 0x40B9CF4: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1101.0) ==11308== by 0x1000C73C: affile_dd_new (affile.c:607) ==11308== by 0x10007A80: yyparse (cfg-grammar.y:478) ==11308== by 0x1000528C: cfg_new (cfg.c:284) ==11308== by 0x100042D0: main (main.c:424) ==11308==
By inspection I see that the call tree from cfg_new (cfg.c:284) upwards applies when a SIGHUP is handled so I'm guessing this may be the cause. I don't know how to send a SIGHUP to an app that is running under valgrind, so I haven't confirmed this.
The interesting thing is that the size of the leak I'm seeing is a lot smaller (4-8bytes) than the amount I would expect if the chunk allocated in affile_dd_new is getting lost.
I'm running a snapshot from 2.0.0 - 2.0.0+20061212.
I check the release note for 2.0.4 but didn't see any mention of memory leak fixes.
You only seek leaks when SIGHUP is sent, or also during normal operation? -- Bazsi