Hi Bazsi, I've finally found the memory leak I noticed when syslog-ng handles a SIGHUP. It turned out that there were 3 leaks. They are not very big so perhaps not significant for most users but in my system there is limited memory and frequent use of SIGHUP. I've attached a patch that I believe resolves the leaks. Valgrind seems to like it. However please let me know if there are any problems with it. This is the first time I've really gotten into the code so I'm sure I may have overlooked something. Please note that my original fix was made and tested on 2.0.0+20061212, but the attached patch is for 2.0.4. I didn't notice any differences that would seem to impact the fix, but I may have missed something. Here's a description of the changes: cfg-grammar.y cfg-grammar.c - The template reference counter gets incremented in the template lookup function, so remove the second increment here. Otherwise the counter never gets back to 0 and the template won't be able to be deleted. affile.c affile_dd_deinit: + Unreference the writer after de-initing it. The unreference will cause the writer to be deleted, which causes it to unreference this destination driver (a circular reference). When the call to affile_dd_free is made via cfg_free() the ref counter will be 1, allowing a final decrement and hence the removal of the destination diver. Previously the counter was 2 due to the writer reference, which prevented the destination driver from being removed. templates.c + When freeing a template also deallocate the memory used by a compiled template. regards Anthony
"anthony lineham" <anthony.lineham@alliedtelesis.co.nz> 07/09/07 8:56 AM >>>
Balazs Scheidler <bazsi@balabit.hu> 07/06/07 11:54 PM >>> 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?
I'm only seeing the leak when SIGHUP is sent. I haven't noticed anything associated with normal operation. _______________________________________________ syslog- ng maillist - syslog- ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog- ng Frequently asked questions at http://www.campin.net/syslog- ng/faq.html