[Bug 18] New: random signal 6 in raise() from libc
https://bugzilla.balabit.com/show_bug.cgi?id=18 Summary: random signal 6 in raise() from libc Product: syslog-ng Version: 2.0.x Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi@balabit.hu ReportedBy: anders.henke@1und1.de Type of the Report: --- Estimated Hours: 0.0 On my central log server, syslog-ng 2.0.7 randomly aborts (signal 6); I haven't noticed this earlier (as syslog-ng is respawned from init), but according to 8 core dumps, it's always at the same function within libc; I wonder why only syslog-ng triggers this. # for I in core.syslog-ng.sig6.* ; do echo "# $I" ; echo quit | gdb /sbin/syslog-ng $I 2>&1 ; done > sig6 # grep raise sig6 #0 0x00007fea95e9a07b in raise () from /lib/libc.so.6 #0 0x00007f1cacf7807b in raise () from /lib/libc.so.6 #0 0x00007ffc4365d07b in raise () from /lib/libc.so.6 #0 0x00007f8f86a9407b in raise () from /lib/libc.so.6 #0 0x00007f45933aa07b in raise () from /lib/libc.so.6 #0 0x00007fcd9195007b in raise () from /lib/libc.so.6 #0 0x00007f01ea4bd07b in raise () from /lib/libc.so.6 #0 0x00007f83c135a07b in raise () from /lib/libc.so.6 Sample excerpt: # core.syslog-ng.sig6.16915 GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/librt.so.1...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib/libnss_compat.so.2...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnss_nis.so.2...done. Loaded symbols for /lib/libnss_nis.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Failed to read a valid object file image from memory. Core was generated by `/sbin/syslog-ng -f /var/run/syslog-ng.conf.521 -F -p /var/run/syslog-ng.pid.521'. Program terminated with signal 6, Aborted. #0 0x00007fea95e9a07b in raise () from /lib/libc.so.6 (gdb) I'm running Debian Linux 4.0 (Etch) in 64-Bit-flavour. Syslog-NG 2.0.7 has been compiled using the supplied debian/rules file, except two changes: don't strip the symbol table from the binary and use --enable-debug. -- 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=18 --- Comment #1 from Anders Henke <anders.henke@1und1.de> 2008-02-01 15:25:10 --- Ouch, the backtrace has been missing ... #0 0x00007fea95e9a07b in raise () from /lib/libc.so.6 #1 0x00007fea95e9b84e in abort () from /lib/libc.so.6 #2 0x00000000004237db in g_logv () #3 0x0000000000423861 in g_log () #4 0x00000000004226ea in g_malloc0 () #5 0x000000000040de0c in log_msg_new ( msg=0x7fea94f36f50 "<43> syslog-ng[16915]: gmem.c:172: failed to allocate 128 bytes\n", length=64, saddr=0x0, flags=6, bad_hostname=0x0) at logmsg.c:648 #6 0x00000000004051fd in msg_send_internal_message (prio=43, msg=0x7fea94f34130 "gmem.c:172: failed to allocate 128 bytes") at messages.c:59 #7 0x0000000000405400 in msg_log_func (log_domain=0x445eb2 "GLib", log_flags=6, msg=0x7fea94f34130 "gmem.c:172: failed to allocate 128 bytes", user_data=0x0) at messages.c:112 Ok, the abort seems to relate to an out of memory condition; I'm running syslog-ng with ulimits (128M) to prevent syslog-ng from screwing up the box due to some memory leak (I've quite often seen memory leaks, but didn't yet have the time to check them back). I'll be tracing it in valgrind over the weekend ... -- 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=18 --- Comment #2 from Balazs Scheidler <bazsi@balabit.hu> 2008-02-01 16:49:23 --- *** Bug 17 has been marked as a duplicate of this bug. *** -- 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=18 --- Comment #3 from Balazs Scheidler <bazsi@balabit.hu> 2008-02-01 17:00:45 --- syslog-ng, just like GLib assumes that malloc() never fails, and aborts in this case. So the question is whether syslog-ng actually leaks memory, or it uses the available 128M for legitimate reasons (log_fifo_size for instance) The valgrind dump would be useful, but please use the following environment options: G_SLICE=always-malloc before starting valgrind. Thanks in advance. -- 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=18 Anders Henke <anders.henke@1und1.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution| |INVALID Status|NEW |RESOLVED --- Comment #4 from Anders Henke <anders.henke@1und1.de> 2008-02-05 09:44:10 --- While checking back the valgrind logs, there wasn't any serious sign of a memory leak. After setting the ulimit to a higher value (256M), syslog-ng now uses about 26 to 41M (I'm running multiple instances in parallel on different ports) and hasn't crashed since about that reconfiguration. -- 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=18 Balazs Scheidler <bazsi@balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED --- Comment #5 from Balazs Scheidler <bazsi@balabit.hu> 2008-02-05 10:05:32 --- Thanks for reporting back. -- 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