Parser-DB Memory Leak
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 Here is my configuration: @version: 3.0 options { }; source s_tcp { tcp(ip(0.0.0.0) port(445)); }; parser p_db { db-parser(); }; filter f_security_class { match("security" value(".classifier.class")); }; filter f_class_unknown { match("unknown" value(".classifier.class")); }; filter f_not_class_unknown { not match("unknown" value(".classifier.class")); }; filter f_FIREWALL_ACCESS_DENY { match("2" value(".classifier.rule_id")); }; template t_FIREWALL_ACCESS_DENY { template("$R_UNIXTIME\t$SOURCEIP\t$FACILITY\t$PROGRAM\t${.classifier.class}\t${.classifier.rule_id}\t${FIREWALL.proto}\t${FIREWALL.o_int}\t${FIREWALL.srcip}\t${FIREWALL.srcport}\t${FIREWALL.i_int}\t${FIREWALL.dstip}\t${FIREWALL.dstport}\t${FIREWALL.access_group}\t${FWSM.PRIORITY}\t${FWSM.MSG_CODE}\t${MSGONLY}\n"); }; destination d_FIREWALL_ACCESS_DENY { fifo("/tmp/db_parsed_fifo", template(t_FIREWALL_ACCESS_DENY)); }; filter f_FIREWALL_CONNECTION_END { match("3" value(".classifier.rule_id")); }; template t_FIREWALL_CONNECTION_END { template("$R_UNIXTIME\t$SOURCEIP\t$FACILITY\t$PROGRAM\t${.classifier.class}\t${.classifier.rule_id}\t${FIREWALL.proto}\t${FIREWALL.o_int}\t${FIREWALL.srcip}\t${FIREWALL.srcport}\t${FIREWALL.i_int}\t${FIREWALL.dstip}\t${FIREWALL.dstport}\t${FIREWALL.conn_duration}\t${FIREWALL.conn_bytes}\t$MSGONLY\n"); }; destination d_FIREWALL_CONNECTION_END { fifo("/tmp/db_parsed_fifo", template(t_FIREWALL_CONNECTION_END)); }; template t_DEFAULT { template("$R_UNIXTIME\t$SOURCEIP\t\$FACILITY\t$PROGRAM\t1\t1\t$MSGONLY\n"); }; destination d_default_fifo { fifo("/tmp/db_parsed_fifo", template(t_DEFAULT)); }; log { source(s_tcp); log { parser(p_db); filter(f_not_class_unknown); log { filter(f_FIREWALL_ACCESS_DENY); destination(d_FIREWALL_ACCESS_DENY); }; log { filter(f_FIREWALL_CONNECTION_END); destination(d_FIREWALL_CONNECTION_END); }; flags(final); }; log { destination(d_default_fifo); }; }; var/patterndb.xml: <patterndb version='1' pub_date='2009-04-16'> <program name='FWSM'> <pattern>%FWSM</pattern> <rule id='2' class='2'> <pattern>Deny@QSTRING:FIREWALL.proto: @src@QSTRING:FIREWALL.o_int: :@@IPv4:FIREWALL.srcip:@/@NUMBER:FIREWALL.srcport:@ dst@QSTRING:FIREWALL.i_int: :@@IPv4:FIREWALL.dstip:@/@NUMBER:FIREWALL.dstport:@ by access-group @QSTRING:FIREWALL.access_group:"@</pattern> </rule> <rule id='3' class='3'> <pattern>Teardown@QSTRING:FIREWALL.proto: @connection @NUMBER::@ for@QSTRING:FIREWALL.o_int: :@@IPv4:FIREWALL.srcip:@ /@NUMBER:FIREWALL.srcport@ to@QSTRING:FIREWALL.i_int: :@@IPv4:FIREWALL.dstip:@/@NUMBER:FIREWALL.dstport@ duration@QSTRING:FIREWALL.conn_duration: @bytes @NUMBER:FIREWALL.conn_bytes:@</pattern> </rule> </program> </patterndb> syslog-ng -V syslog-ng 3.0.1+binpkg4 Revision: ssh+git://bazsi@git.balabit //var/scm/git/syslog-ng/syslog-ng-ose--mainline--3.0#master#555574a984eaef9410a2869db0af1be0d52b269b Compile-Date: Apr 16 2009 14:42:21 Enable-Threads: on Enable-Debug: off Enable-GProf: off Enable-Memtrace: off Enable-Sun-STREAMS: off Enable-Sun-Door: off Enable-IPv6: on Enable-Spoof-Source: off Enable-TCP-Wrapper: on Enable-SSL: on Enable-SQL: on Enable-Linux-Caps: off Enable-Pcre: on Should I recompile with memtrace on? Thanks, Martin
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 -- Key fingerprint = F78C 25CA 5F88 6FAF EA21 779D 3279 9F9E 1155 670D
On Fri, 2009-04-24 at 18:28 +0200, ILLES, Marton wrote:
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
I think I have got it: 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=778cb9b273664251... best, Marton -- Key fingerprint = F78C 25CA 5F88 6FAF EA21 779D 3279 9F9E 1155 670D
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. --Martin On 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:
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
I think I have got it:
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=778cb9b273664251...
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
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 On Fri, Apr 24, 2009 at 1:29 PM, Martin Holste <mcholste@gmail.com> wrote:
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.
--Martin
On 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:
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
I think I have got it:
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=778cb9b273664251...
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
On Fri, 2009-04-24 at 16:20 -0500, Martin Holste wrote:
Ok, looks like it's still leaking. I haven't used valgrind before, but here is the output with leak-check=full:
==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)
Hmm, I tried to reproduce the problem, but so far without any luck. My guess is that only some message trigger this problem probably because of a partial match. Could you send me some example messages when you experience this problem? Marton
Hopefully this helps!
--Martin
On Fri, Apr 24, 2009 at 1:29 PM, Martin Holste <mcholste@gmail.com> wrote: 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.
--Martin
On 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: > 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
I think I have got it:
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=778cb9b273664251...
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
______________________________________________________________________________ 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
-- Key fingerprint = F78C 25CA 5F88 6FAF EA21 779D 3279 9F9E 1155 670D
On Sat, 2009-04-25 at 17:01 +0200, ILLES, Marton wrote:
On Fri, 2009-04-24 at 16:20 -0500, Martin Holste wrote:
Ok, looks like it's still leaking. I haven't used valgrind before, but here is the output with leak-check=full:
==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)
Hmm, I tried to reproduce the problem, but so far without any luck. My guess is that only some message trigger this problem probably because of a partial match. Could you send me some example messages when you experience this problem?
The problem was when the parser did not have a name configured and syslog-ng incorrectly checked this situation and always malloced 1 byte for the name which was never freed. Thanks Martin for helping tracking it down. Here is the patch: commit a5f7bb56dc1c83431f531bf5726512f28c0e75e8 Author: Marton Illes <marci@balabit.hu> Date: Sat Apr 25 19:02:53 2009 +0200 fixed a memory leak around parser match storing, check for parser node name length Reported by: Martin Holste diff --git a/src/radix.c b/src/radix.c index 2caa2a1..787daff 100644 --- a/src/radix.c +++ b/src/radix.c @@ -691,7 +691,7 @@ r_find_node(RNode *root, gchar *whole_key, gchar *key, gint keylen, GArray *matc match->ofs = match->ofs + (key + i) - whole_key; match->len = match->len + len; } - if (parser_node->name) + if (parser_node->name_len) *match_name = g_strndup(parser_node->name, parser_node->name_len); else *match_name = NULL; It is also pushed to my git tree. cheers, Marton
Marton
Hopefully this helps!
--Martin
On Fri, Apr 24, 2009 at 1:29 PM, Martin Holste <mcholste@gmail.com> wrote: 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.
--Martin
On 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: > 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
I think I have got it:
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=778cb9b273664251...
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
______________________________________________________________________________ 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
-- Key fingerprint = F78C 25CA 5F88 6FAF EA21 779D 3279 9F9E 1155 670D
I tried compiling with memtrace, and it segfaults right away no matter what on memtrace.c line 450. I will try running with valgrind and let you know. --Martin On Fri, Apr 24, 2009 at 11:28 AM, ILLES, Marton <illes.marton@balabit.hu>wrote:
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 -- 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
On Fri, 2009-04-24 at 12:30 -0500, Martin Holste wrote:
I tried compiling with memtrace, and it segfaults right away no matter what on memtrace.c line 450. I will try running with valgrind and let you know.
memtrace does not work well (e.g. it immediately segfaults) if the slice allocator is enabled in glib. So to get any success with memtrace, you need to specify G_SLICE=always-malloc in the environment before starting up syslog-ng. However, for simple memleak debugging valgrind is better than memtrace, so you should stick to that. -- Bazsi
participants (4)
-
Balazs Scheidler
-
ILLES, Marton
-
Martin Holste
-
okapareeya＠hotmail.com