[Bug 139] New: syslog-ng crashes on SIGHUP when rewrite used in multiple log{} declarations
https://bugzilla.balabit.com/show_bug.cgi?id=139 Summary: syslog-ng crashes on SIGHUP when rewrite used in multiple log{} declarations Product: syslog-ng Version: 3.2.x Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: unspecified Component: syslog-ng AssignedTo: bazsi@balabit.hu ReportedBy: bugzilla.syslogng@feystorm.net Type of the Report: --- Estimated Hours: 0.0 This is for version 3.3.1 which isnt an available version in the bug tracker. I've managed to create a situation where syslog-ng crashes when it receives a SIGHUP, and a certain rewrite has been used in at least 3 different log{} declarations. Below is the extremely stripped down configuration I've created which duplicates the issue. With the below configuration, when syslog-ng receives a HUP, it will get a segfault in malloc_consolidate(). Additionally, the process which monitors syslog-ng for crashing doesnt appear to have a signal handler for SIGHUP, so the monitor process will die when it gets a HUP. This is a problem, at least on redhat as the redhat init script sends a HUP to both the monitor process and the real worker process when the init script is called with `reload` @version: 3.3 @include "scl.conf" source s_local { system(); }; rewrite r_fext { #set("$LEVEL",value('FEXT')); subst('foo','bar', value('FEXT') type('string')); }; log { source(s_local); rewrite(r_fext); }; log { source(s_local); rewrite(r_fext); }; log { source(s_local); rewrite(r_fext); }; -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=139 --- Comment #1 from Patrick <bugzilla.syslogng@feystorm.net> 2011-10-17 22:40:21 --- gdb stack trace Program received signal SIGSEGV, Segmentation fault. 0x00000034e6c705a4 in malloc_consolidate () from /lib64/libc.so.6 (gdb) where #0 0x00000034e6c705a4 in malloc_consolidate () from /lib64/libc.so.6 #1 0x00000034e6c72bbc in _int_malloc () from /lib64/libc.so.6 #2 0x00000034e6c74aad in calloc () from /lib64/libc.so.6 #3 0x00000034e6809deb in _dl_new_object () from /lib64/ld-linux-x86-64.so.2 #4 0x00000034e6805a6c in _dl_map_object_from_fd () from /lib64/ld-linux-x86-64.so.2 #5 0x00000034e68076d1 in _dl_map_object () from /lib64/ld-linux-x86-64.so.2 #6 0x00000034e6810bf6 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #7 0x00000034e680ce46 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #8 0x00000034e68105fc in _dl_open () from /lib64/ld-linux-x86-64.so.2 #9 0x00000034e6d08f50 in do_dlopen () from /lib64/libc.so.6 #10 0x00000034e680ce46 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #11 0x00000034e6d090b7 in __libc_dlopen_mode () from /lib64/libc.so.6 #12 0x00000034e6ce629a in init () from /lib64/libc.so.6 #13 0x00000034e740c083 in pthread_once () from /lib64/libpthread.so.0 #14 0x00000034e6ce6337 in backtrace () from /lib64/libc.so.6 #15 0x00000034e6c6a9af in __libc_message () from /lib64/libc.so.6 #16 0x00000034e6c7245f in _int_free () from /lib64/libc.so.6 #17 0x00000034e6c728bb in free () from /lib64/libc.so.6 #18 0x00002b561993ca88 in log_matcher_unref (s=0x9ba5c60) at logmatcher.c:879 #19 0x00002b5619948831 in log_rewrite_subst_free (s=0x9b85920) at logrewrite.c:175 #20 0x00002b56199406d7 in log_pipe_unref (self=0x9b85920) at logpipe.c:68 #21 0x00002b561992f815 in log_center_free (self=0x9b859c0) at center.c:593 #22 0x00002b5619930a98 in cfg_free (self=0x9b7d000) at cfg.c:459 #23 0x00002b561994f479 in main_loop_reload_config_apply () at mainloop.c:493 #24 0x00002b561994f321 in main_loop_io_worker_sync_call (func=0x2b561994f3c0 <main_loop_reload_config_apply>) at mainloop.c:443 #25 0x00002b561994f6a5 in main_loop_reload_config_initiate () at mainloop.c:561 #26 0x00002b561994f6f6 in sig_hup_handler (s=0x0) at mainloop.c:594 #27 0x00002b5619994f04 in iv_signal_event (_this=0x2b5619bca280) at iv_signal.c:80 #28 0x00002b5619994b3b in iv_event_raw_got_event (_this=0x2b5619bca2a8) at iv_event_raw.c:82 #29 0x00002b56199910a5 in iv_run_active_list (active=0x7fff333fb380) at iv_main.c:219 #30 0x00002b56199912e3 in iv_main () at iv_main.c:269 #31 0x00002b561994fac0 in main_loop_run () at mainloop.c:722 #32 0x000000000040175c in main (argc=1, argv=0x7fff333fb4f8) at main.c:260 -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=139 --- Comment #2 from Balazs Scheidler <bazsi@balabit.hu> 2011-10-20 12:38:24 --- Thanks for the report. It seems to be a reference counting issue on the underlying Rewrite object, hopefully I can have a stab at this in the coming days. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=139 Balazs Scheidler <bazsi@balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution| |FIXED Status|NEW |RESOLVED --- Comment #3 from Balazs Scheidler <bazsi@balabit.hu> 2011-10-23 09:08:52 --- Committed this patch which seems to fix it for me: commit 46bbdf9a107409e320450f9c4b6a82c2cf9f36af Author: Balazs Scheidler <bazsi@balabit.hu> Date: Sun Oct 23 09:08:08 2011 +0200 LogMatcher: fixed reference counting A reference count was added to LogMatcher instances, but it contained several critical issues: - the refcount wasn't initialized - the instance got freed when the refcount was non-zero Essentially the only case it worked when a rewrite rule was referenced from only _one_ location and in that case it leaked the matcher instance. Kudos for the great diagnosis in the original report, reported as ticket #139 in bugzilla.balabit.com. Reported-By: Patrick <bugzilla.syslogng@feystorm.net> Cc: syslog-ng-stable@balabit.com Signed-off-by: Balazs Scheidler <bazsi@balabit.hu> -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=139 Balazs Scheidler <bazsi@balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |3.3.2 Version|3.2.x |3.3.x --- Comment #4 from Balazs Scheidler <bazsi@balabit.hu> 2011-10-23 09:11:07 --- fixed up version fields. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
bugzilla＠bugzilla.balabit.com