Red Hat Bugzilla – Bug 1010506
[abrt] systemd-204-11.fc19: crash: Process /usr/lib/systemd/systemd was killed by signal 11 (SIGSEGV)
Last modified: 2013-10-06 22:35:39 EDT
Version-Release number of selected component:
cmdline: /usr/lib/systemd/systemd --switched-root --system --deserialize 20
runlevel: N 5
Thread no. 1 (10 frames)
#2 crash at ../src/core/main.c:142
#4 free@plt at /lib/libc.so.6
#5 _IO_vfprintf_internal at vfprintf.c:1635
#6 ___vsnprintf_chk at vsnprintf_chk.c:63
#7 ___snprintf_chk at snprintf_chk.c:35
#8 snprintf at /usr/include/bits/stdio2.h:64
#9 log_do_header at ../src/shared/log.c:441
#10 log_struct_internal at ../src/shared/log.c:746
#11 process_event at ../src/core/manager.c:1641
#12 manager_loop at ../src/core/manager.c:1755
Created attachment 800771 [details]
Created attachment 800772 [details]
Created attachment 800773 [details]
Created attachment 800774 [details]
Created attachment 800775 [details]
Created attachment 800776 [details]
Created attachment 800777 [details]
Created attachment 800778 [details]
Created attachment 800779 [details]
Created attachment 800780 [details]
I had the same running on systemd-204-15.fc19.i686 as well.
(In reply to Damian Wrobel from comment #11)
> I had the same running on systemd-204-15.fc19.i686 as well.
It was 100% reproducible while resuming laptop causing the machine entirely unusable.
Recompiling and installing systemd-207-4 from koji to F19 fixes the issue for me.
Hm, this failure is in a logging statement. But it is a very simple logging statement, with a static string and no arguments. As simple as it gets. The logging implementation is pretty complex, but if we had bugs there, I suppose we would see more failures, since the logging code is used all the time. Most likely explanation is that this is a memory corruption that is triggered by some specific sequence of events during the suspend, but actually happens outside of the call stack shown in the backtrace.
I've made an attempt to compile the aforementioned 207-4 srpm having enabled the address sanitizer with the following change:
diff --git a/configure.ac b/configure.ac
index d3f853f..492befd 100644
@@ -102,6 +102,7 @@ if test -z "$GPERF" ; then
CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\
+ -fsanitize=address -fno-omit-frame-pointer \
@@ -151,6 +152,7 @@ AS_CASE([$CFLAGS], [*-O[[12345g\ ]]*],
CC_CHECK_FLAGS_APPEND([with_ldflags], [LDFLAGS], [\
+ -Wc,-fsanitize=address \
unfortunately the build failed with the following errors:
./.libs/libsystemd-machine-core.a(libsystemd_machine_core_la-machined-dbus.o): In function `bus_manager_create_machine':
/home/dw/projects/rpmbuild/BUILD/systemd-207/build3/../src/machine/machined-dbus.c:204: undefined reference to `manager_add_machine'
./.libs/libsystemd-machine-core.a(libsystemd_machine_core_la-machined-dbus.o): In function `manager_message_handler':
/home/dw/projects/rpmbuild/BUILD/systemd-207/build3/../src/machine/machined-dbus.c:307: undefined reference to `manager_get_machine_by_pid'
collect2: error: ld returned 1 exit status
Makefile:8553: recipe for target 'test-machine-tables' failed
This looks like a Makefile's problem. If you could look at it and suggest what should be corrected, I'm willing to test such a version.
I've pushed fixes into systemd git for the build issue with -fsanitize=address. You should be able to do
./configure --enable-address-sanitizer --disable-introspection CFLAGS='-g ...'
and it should built an address sanitizer enabled version. --disable-introspection is required because the ldflags mess up the introspection call, and I haven't found a way to hook into the right place.
Relevant commits are 8097ab4f, and 732bfe0, bd16acf, 2b3ab29d.
*** This bug has been marked as a duplicate of bug 1010603 ***