Ok, looks like it's still leaking. I haven't used valgrind before, but here is the output with leak-check=full:
==27470==
==27470== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 42 from 1)
==27470== malloc/free: in use at exit: 464,868 bytes in 22,518 blocks.
==27470== malloc/free: 939,731 allocs, 917,213 frees, 30,806,969 bytes allocated.
==27470== For counts of detected errors, rerun with: -v
==27470== searching for pointers to 22,518 not-freed blocks.
==27470== checked 690,580 bytes.
==27470==
==27470== 1,488 bytes in 6 blocks are possibly lost in loss record 4 of 13
==27470== at 0x40045C0: memalign (vg_replace_malloc.c:332)
==27470== by 0x400461A: posix_memalign (vg_replace_malloc.c:425)
==27470== by 0x4DDAC4: (within /lib/libglib-2.0.so.0.1200.3)
==27470== by 0x4DE4FE: g_slice_alloc (in /lib/libglib-2.0.so.0.1200.3)
==27470== by 0x4A9CA8: g_array_sized_new (in /lib/libglib-2.0.so.0.1200.3)
==27470== by 0x4A9DB6: g_array_new (in /lib/libglib-2.0.so.0.1200.3)
==27470== by 0x4E58E6: g_static_private_set (in /lib/libglib-2.0.so.0.1200.3)
==27470== by 0x4EC04D: g_get_charset (in /lib/libglib-2.0.so.0.1200.3)
==27470== by 0x4B2B1A: g_locale_to_utf8 (in /lib/libglib-2.0.so.0.1200.3)
==27470== by 0x4D35CC: (within /lib/libglib-2.0.so.0.1200.3)
==27470== by 0x4D3F02: (within /lib/libglib-2.0.so.0.1200.3)
==27470== by 0x4D4461: g_option_context_parse (in /lib/libglib-2.0.so.0.1200.3)
==27470==
==27470==
==27470== 2,040 bytes in 1 blocks are definitely lost in loss record 6 of 13
==27470== at 0x40046FF: calloc (vg_replace_malloc.c:279)
==27470== by 0x4CE57D: g_malloc0 (in /lib/libglib-2.0.so.0.1200.3)
==27470== by 0x4DE2F7: g_slice_alloc (in /lib/libglib-2.0.so.0.1200.3)
==27470== by 0x4C4FDA: g_list_append (in /lib/libglib-2.0.so.0.1200.3)
==27470== by 0x4D33BC: g_option_context_add_group (in /lib/libglib-2.0.so.0.1200.3)
==27470== by 0x8066F44: g_process_add_option_group (in /usr/local/syslog-ng-3.0-git/sbin/syslog-ng)
==27470== by 0x804E15D: main (in /usr/local/syslog-ng-3.0-git/sbin/syslog-ng)
==27470==
==27470==
==27470== 19,854 (18,775 direct, 1,079 indirect) bytes in 18,684 blocks are definitely lost in loss record 11 of 13
==27470== at 0x40053C0: malloc (vg_replace_malloc.c:149)
==27470== by 0x4CE615: g_malloc (in /lib/libglib-2.0.so.0.1200.3)
==27470== by 0x4E06A0: g_strndup (in /lib/libglib-2.0.so.0.1200.3)
==27470== by 0x807D30B: r_find_node (in /usr/local/syslog-ng-3.0-git/sbin/syslog-ng)
==27470== by 0x807D0F8: r_find_node (in /usr/local/syslog-ng-3.0-git/sbin/syslog-ng)
==27470== by 0x807D258: r_find_node (in /usr/local/syslog-ng-3.0-git/sbin/syslog-ng)
==27470== by 0x807D0F8: r_find_node (in /usr/local/syslog-ng-3.0-git/sbin/syslog-ng)
==27470== by 0x807AA5F: log_pattern_database_lookup (in /usr/local/syslog-ng-3.0-git/sbin/syslog-ng)
==27470== by 0x8062C0C: log_db_parser_process (in /usr/local/syslog-ng-3.0-git/sbin/syslog-ng)
==27470== by 0x8061D8E: log_parser_process (in /usr/local/syslog-ng-3.0-git/sbin/syslog-ng)
==27470== by 0x8062D70: log_parser_rule_process (in /usr/local/syslog-ng-3.0-git/sbin/syslog-ng)
==27470== by 0x8062F4D: log_process_rule_process (in /usr/local/syslog-ng-3.0-git/sbin/syslog-ng)
==27470==
==27470== LEAK SUMMARY:
==27470== definitely lost: 20,815 bytes in 18,685 blocks.
==27470== indirectly lost: 1,079 bytes in 22 blocks.
==27470== possibly lost: 1,488 bytes in 6 blocks.
==27470== still reachable: 441,486 bytes in 3,805 blocks.
==27470== suppressed: 0 bytes in 0 blocks.
==27470== Reachable blocks (those to which a pointer was found) are not shown.
==27470== To see them, rerun with: --show-reachable=yes
Hopefully this helps!
--Martin
Wow! That was quick! I'm running the new code now, but it will take a few hours to see if the memory grows too large. Thanks for the quick commit.
--MartinOn Fri, Apr 24, 2009 at 12:29 PM, ILLES, Marton <illes.marton@balabit.hu> wrote:
On Fri, 2009-04-24 at 18:28 +0200, ILLES, Marton wrote:I think I have got it:
> On Fri, 2009-04-24 at 10:29 -0500, Martin Holste wrote:
> > I'm running tests with the db-parser() parser module and finding that
> > the memory grows exponentially until the program finally dies with:
> >
> > ***MEMORY-ERROR***: syslog-ng[2769]: GSlice: failed to allocate 248
> > bytes (alignment: 256): Cannot allocate memory
> >
>
> snip
>
> > Should I recompile with memtrace on?
> >
>
> Running it in valgrind would be even more useful also enabling core
> might help as well.
>
> M
commit 778cb9b27366425153a6141d4966a1a464e97e79
Author: Marton Illes <marci@balabit.hu>
Date: Fri Apr 24 19:24:40 2009 +0200
fixed a memory leak in db-parser() dynamic value handling
Reported by: Martin Holste
diff --git a/src/logpatterns.c b/src/logpatterns.c
index f1012eb..fda9088 100644
--- a/src/logpatterns.c
+++ b/src/logpatterns.c
@@ -312,6 +312,7 @@ log_pattern_database_lookup(LogPatternDatabase
*self, LogMessage *msg)
*/
g_ptr_array_free(match_names, TRUE);
+ g_array_free(matches, FALSE);
return ((LogDBResult *) msg_node->value);
}
g_ptr_array_free(match_names, TRUE);
Also in my git tree, please give it a try.
http://git.balabit.hu/?p=marci/syslog-ng-3.0.git;a=commit;h=778cb9b27366425153a6141d4966a1a464e97e79
best,
Marton
--
Key fingerprint = F78C 25CA 5F88 6FAF EA21 779D 3279 9F9E 1155 670D
______________________________________________________________________________
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
FAQ: http://www.campin.net/syslog-ng/faq.html