[Bug 237] New: syslog-ng 3.4.2 (and 3.3.10): test failures in Fedora 18
https://bugzilla.balabit.com/show_bug.cgi?id=237 Summary: syslog-ng 3.4.2 (and 3.3.10): test failures in Fedora 18 Product: syslog-ng Version: 3.4.x Platform: PC OS/Version: Mac OS Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi@balabit.hu ReportedBy: jpo@di.uminho.pt Type of the Report: --- Estimated Hours: 0.0 The syslog-ng 3.4.2 (and 3.3.10) test suite fails in Fedora 18: ---------- ... $DATE ${HOST:--} ${PROGRAM:--} ${PID:--} ${MSGID:--} ${SDATA:--} $MSG speed: 1056859.015 msg/sec *** glibc detected *** /home/fedora/rpms/BUILD/syslog-ng-3.4.2/tests/unit/.libs/lt-test_template_speed: free(): invalid pointer: 0x0000003a831b1c68 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3a82e7ca8e] /lib64/libglib-2.0.so.0(g_mutex_free+0x9)[0x3a84a1c719] /lib64/libglib-2.0.so.0(g_static_mutex_free+0x16)[0x3a84a1ca66] /home/fedora/rpms/BUILDROOT/syslog-ng-3.4.2-0.1.fc18.x86_64//usr/lib64/libsyslog-ng-3.4.2.so(crypto_deinit+0x4e)[0x7f43c2fef0be] /lib64/ld-linux-x86-64.so.2[0x3a82a0f5f7] /lib64/libc.so.6[0x3a82e38df1] /lib64/libc.so.6[0x3a82e38e75] /lib64/libc.so.6(__libc_start_main+0xfc)[0x3a82e21a0c] /home/fedora/rpms/BUILD/syslog-ng-3.4.2/tests/unit/.libs/lt-test_template_speed[0x401681] ======= Memory map: ======== 00400000-00403000 r-xp 00000000 08:02 1863099 /home/fedora/rpms/BUILD/syslog-ng-3.4.2/tests/unit/.libs/lt-test_template_speed 00602000-00603000 r--p 00002000 08:02 1863099 /home/fedora/rpms/BUILD/syslog-ng-3.4.2/tests/unit/.libs/lt-test_template_speed 00603000-00604000 rw-p 00003000 08:02 1863099 /home/fedora/rpms/BUILD/syslog-ng-3.4.2/tests/unit/.libs/lt-test_template_speed 01f72000-01fb4000 rw-p 00000000 00:00 0 [heap] 3a82a00000-3a82a20000 r-xp 00000000 08:02 828574 /usr/lib64/ld-2.16.so ... 7f43c342c000-7f43c342d000 r--p 0000a000 08:02 1862848 /home/fedora/rpms/BUILDROOT/syslog-ng-3.4.2-0.1.fc18.x86_64/usr/lib64/syslog-ng/libsyslogformat.so 7f43c342d000-7f43c342e000 rw-p 0000b000 08:02 1862848 /home/fedora/rpms/BUILDROOT/syslog-ng-3.4.2-0.1.fc18.x86_64/usr/lib64/syslog-ng/libsyslogformat.so 7f43c342e000-7f43c342f000 rw-p 00000000 00:00 0 7fff57cb7000-7fff57cd8000 rw-p 00000000 00:00 0 [stack] 7fff57cef000-7fff57cf1000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] /bin/sh: line 5: 6107 Aborted (core dumped) ${dir}$tst FAIL: test_template_speed ... ---------- -- 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=237 --- Comment #1 from Peter Czanik <czanik@balabit.hu> 2013-06-05 11:09:04 --- Just tested "make check" on openSUSE 12.3 & factory. There was one failure related to timezone handling, as the "timezone" package was removed from the default build environment. Once I added it back by a "BuildRequires: timezone", "make check" worked fine again. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
From time to time it seems as though syslog-ng crashes, and our logs show supervise/syslog-ng[30493]: Daemon exited due to a deadlock/signal/failure, restarting; exitcode='6' and then the syslog-ng process is restarted. Does the exitcode=6 from the syslog-ng process indicate that a SIGABRT was received by syslog-ng? If not, then what does it mean? If it does, I am trying to figure out who would send SIGABRT to the process. This is an uncommon signal for the OS to send it (unlike SIGSEGV os SIGBUS) and no human sent it a signal. Can anyone help me understand where the SIGABRT comes from? Evan.
It's in lib/gprocess.c The supervisor process sends SIGABRT (most likely to dump core for further analysis) and switches to SIGKILL later when the daemon is still there. I don't see that the OSE could enter that code path so I assume you're using PE so I'm sure the BalaBit guys will follow up with you quite soon. On Wed, Jun 5, 2013 at 10:31 PM, Evan Rempel <erempel@uvic.ca> wrote:
From time to time it seems as though syslog-ng crashes, and our logs show
supervise/syslog-ng[30493]: Daemon exited due to a deadlock/signal/failure, restarting; exitcode='6'
and then the syslog-ng process is restarted.
Does the exitcode=6 from the syslog-ng process indicate that a SIGABRT was received by syslog-ng?
If not, then what does it mean?
If it does, I am trying to figure out who would send SIGABRT to the process. This is an uncommon signal for the OS to send it (unlike SIGSEGV os SIGBUS) and no human sent it a signal.
Can anyone help me understand where the SIGABRT comes from?
Evan.
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
Two comments. 1. I am running the OSE, so it would seem that the OSE can enter that code path :-) 2. Under what conditions would the supervisor send a SIGABRT to its child? Evan. On 06/06/2013 01:59 AM, Sandor Geller wrote:
It's in lib/gprocess.c
The supervisor process sends SIGABRT (most likely to dump core for further analysis) and switches to SIGKILL later when the daemon is still there. I don't see that the OSE could enter that code path so I assume you're using PE so I'm sure the BalaBit guys will follow up with you quite soon.
On Wed, Jun 5, 2013 at 10:31 PM, Evan Rempel <erempel@uvic.ca <mailto:erempel@uvic.ca>> wrote:
From time to time it seems as though syslog-ng crashes, and our logs show
supervise/syslog-ng[30493]: Daemon exited due to a deadlock/signal/failure, restarting; exitcode='6'
and then the syslog-ng process is restarted.
Does the exitcode=6 from the syslog-ng process indicate that a SIGABRT was received by syslog-ng?
If not, then what does it mean?
If it does, I am trying to figure out who would send SIGABRT to the process. This is an uncommon signal for the OS to send it (unlike SIGSEGV os SIGBUS) and no human sent it a signal.
Can anyone help me understand where the SIGABRT comes from?
Evan. ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
-- Evan Rempel erempel@uvic.ca Senior Systems Administrator 250.721.7691 Data Centre Services, University Systems, University of Victoria
It might b a failed assertion by the child. On Jun 6, 2013 5:06 PM, "Evan Rempel" <erempel@uvic.ca> wrote:
Two comments.
1. I am running the OSE, so it would seem that the OSE can enter that code path :-)
2. Under what conditions would the supervisor send a SIGABRT to its child?
Evan.
On 06/06/2013 01:59 AM, Sandor Geller wrote:
It's in lib/gprocess.c
The supervisor process sends SIGABRT (most likely to dump core for further analysis) and switches to SIGKILL later when the daemon is still there. I don't see that the OSE could enter that code path so I assume you're using PE so I'm sure the BalaBit guys will follow up with you quite soon.
On Wed, Jun 5, 2013 at 10:31 PM, Evan Rempel <erempel@uvic.ca <mailto: erempel@uvic.ca>> wrote:
From time to time it seems as though syslog-ng crashes, and our logs show
supervise/syslog-ng[30493]: Daemon exited due to a deadlock/signal/failure, restarting; exitcode='6'
and then the syslog-ng process is restarted.
Does the exitcode=6 from the syslog-ng process indicate that a SIGABRT was received by syslog-ng?
If not, then what does it mean?
If it does, I am trying to figure out who would send SIGABRT to the process. This is an uncommon signal for the OS to send it (unlike SIGSEGV os SIGBUS) and no human sent it a signal.
Can anyone help me understand where the SIGABRT comes from?
Evan.
______________________________________________________________________________
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation:
http://www.balabit.com/support/documentation/?product=syslog-ng
______________________________________________________________________________
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
-- Evan Rempel erempel@uvic.ca Senior Systems Administrator 250.721.7691 Data Centre Services, University Systems, University of Victoria
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
https://bugzilla.balabit.com/show_bug.cgi?id=237 Gergely Nagy <algernon@balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |algernon@balabit.hu AssignedTo|bazsi@balabit.hu |algernon@balabit.hu --- Comment #2 from Gergely Nagy <algernon@balabit.hu> 2013-06-13 13:58:28 --- I can't reproduce this either, at least not on Debian (with all kinds of build flags, etc), valgrind is silent too :/ I'll try again later on a Fedora 18 VM, but a backtrace from the dump, preferably with debug symbols present would be very useful. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (4)
-
Balazs Scheidler
-
bugzilla＠bugzilla.balabit.com
-
Evan Rempel
-
Sandor Geller