FS#36991 - [systemd] Version 207 crashes after suspend tu RAM

Attached to Project: Arch Linux
Opened by Natrio (natrio) - Thursday, 19 September 2013, 18:00 GMT
Last edited by Dave Reisner (falconindy) - Friday, 20 September 2013, 18:52 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

After suspend to RAM I see in log:

Sep 19 21:03:09 first systemd-sleep[973] System resumed.
Sep 19 21:03:09 first systemd[1]: Caught <SEGV>, dumped core as pid 1051.
Sep 19 21:03:09 first systemd[1]: Freezing execution.
Sep 19 21:03:09 first systemd-coredump[1053]: Process 1051 (systemd) dumped core.

$ systemctl
Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused

All other processes are still working.

CPU: Intel Sandy Bridge
Arch: i686
This task depends upon

Closed by  Dave Reisner (falconindy)
Friday, 20 September 2013, 18:52 GMT
Reason for closing:  Upstream
Additional comments about closing:  Upstream kernel bug causing memory corruption, not related to systemd.
Comment by Dave Reisner (falconindy) - Thursday, 19 September 2013, 18:03 GMT
Can you reproduce the crash with debug symbols and post a backtrace from the coredump? This isn't useful as is.
Comment by Natrio (natrio) - Thursday, 19 September 2013, 19:05 GMT
I cat't get usable core dump on systemd.
But, I found similar reports:
https://bbs.archlinux.de/viewtopic.php?pid=311974
https://bbs.archlinux.org/viewtopic.php?pid=1326769
Comment by Dave Reisner (falconindy) - Thursday, 19 September 2013, 19:10 GMT
> I cat't get usable core dump on systemd.
Then I can't really help you.
Comment by Natrio (natrio) - Thursday, 19 September 2013, 19:16 GMT
systemd-coredumpctl dump > /tmp/coredump.700
Comment by Dave Reisner (falconindy) - Thursday, 19 September 2013, 19:20 GMT
If you didn't bother to recompile systemd with debug symbols and reproduce the crash, there's no point in me looking at that....
Comment by Dave Reisner (falconindy) - Thursday, 19 September 2013, 22:25 GMT
You can install systemd-207-5 along with a debug package from my repo:

[falconindy]
Server = http://repo.falconindy.com/$arch

This will give you a useful core dump to get a backtrace from.
Comment by Natrio (natrio) - Friday, 20 September 2013, 06:32 GMT
Thank you.

On other machine:
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping : 9
microcode : 0x17

Reading symbols from /usr/lib/systemd/systemd...Reading symbols from /usr/lib/debug/usr/lib/systemd/systemd.debug...done.
done.
[New LWP 801]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/sbin/init'.
Program terminated with signal 11, Segmentation fault.
#0 0xb76f3424 in __kernel_vsyscall ()
[?1034h(gdb) bt
#0 0xb76f3424 in __kernel_vsyscall ()
#1 0xb761cd76 in raise () from /usr/lib/libpthread.so.0
#2 0x08051778 in crash (sig=11) at src/core/main.c:143
#3 <signal handler called>
#4 0xb7475390 in free@plt () from /usr/lib/libc.so.6
#5 0xb74a2609 in vfprintf () from /usr/lib/libc.so.6
#6 0xb75588e0 in __vsnprintf_chk () from /usr/lib/libc.so.6
#7 0xb7558807 in __snprintf_chk () from /usr/lib/libc.so.6
#8 0x080b04e5 in snprintf (
__fmt=0x810e038 "PRIORITY=%i\nSYSLOG_FACILITY=%i\n%s%.*s%s%s%.*i%s%s%.*s%s%s%.*s%sSYSLOG_IDENTIFIER=%s\n", __n=2048,
__s=0xbfc91f8c "PRIORITY=6\nSYSLOG_FACILITY=3\nCODE_FILE=\267)") at /usr/include/bits/stdio2.h:64
#9 log_do_header (header=header@entry=0xbfc91f8c "PRIORITY=6\nSYSLOG_FACILITY=3\nCODE_FILE=\267)", level=level@entry=30,
file=file@entry=0x80dc52e "src/core/manager.c", line=line@entry=1732,
func=func@entry=0x80ddd36 <__func__.12811> "process_event", object_name=object_name@entry=0x0, object=object@entry=0x0,
size=2048) at src/shared/log.c:445
#10 0x080b1c69 in log_struct_internal (level=30, level@entry=6, file=file@entry=0x80dc52e "src/core/manager.c",
line=line@entry=1732, func=func@entry=0x80ddd36 <__func__.12811> "process_event",
format=format@entry=0x80dd448 "MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x")
at src/shared/log.c:750
#11 0x080590c5 in process_event (ev=0xbfc92848, m=<optimized out>) at src/core/manager.c:1729
#12 manager_loop (m=0x8a7f530) at src/core/manager.c:1854
#13 0x0804f3c0 in main (argc=1, argv=0xbfc92d64) at src/core/main.c:1651
(gdb) quit

Comment by Natrio (natrio) - Friday, 20 September 2013, 07:00 GMT
Other machine, Arch i686 too:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 22
model name : Intel(R) Celeron(R) CPU 560 @ 2.13GHz
stepping : 1
microcode : 0x33

coredump:

Reading symbols from /usr/lib/systemd/systemd...Reading symbols from /usr/lib/debug/usr/lib/systemd/systemd.debug...done.
done.
[New LWP 749]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/sbin/init'.
Program terminated with signal 11, Segmentation fault.
#0 0xb773f424 in __kernel_vsyscall ()
[?1034h(gdb) bt
#0 0xb773f424 in __kernel_vsyscall ()
#1 0xb7670d76 in raise () from /usr/lib/libpthread.so.0
#2 0x08051778 in crash (sig=11) at src/core/main.c:143
#3 <signal handler called>
#4 0xb74c9390 in free@plt () from /usr/lib/libc.so.6
#5 0xb74f6609 in vfprintf () from /usr/lib/libc.so.6
#6 0xb75ac8e0 in __vsnprintf_chk () from /usr/lib/libc.so.6
#7 0xb75ac807 in __snprintf_chk () from /usr/lib/libc.so.6
#8 0x080b04e5 in snprintf (__fmt=0x810e038 "PRIORITY=%i\nSYSLOG_FACILITY=%i\n%s%.*s%s%s%.*i%s%s%.*s%s%s%.*s%sSYSLOG_IDENTIFIER=%s\n", __n=2048,
__s=0xbf85dffc "PRIORITY=6\nSYSLOG_FACILITY=3\nCODE_FILE=\267)") at /usr/include/bits/stdio2.h:64
#9 log_do_header (header=header@entry=0xbf85dffc "PRIORITY=6\nSYSLOG_FACILITY=3\nCODE_FILE=\267)", level=level@entry=30,
file=file@entry=0x80dc52e "src/core/manager.c", line=line@entry=1732, func=func@entry=0x80ddd36 <__func__.12811> "process_event",
object_name=object_name@entry=0x0, object=object@entry=0x0, size=2048) at src/shared/log.c:445
#10 0x080b1c69 in log_struct_internal (level=30, level@entry=6, file=file@entry=0x80dc52e "src/core/manager.c", line=line@entry=1732,
func=func@entry=0x80ddd36 <__func__.12811> "process_event",
format=format@entry=0x80dd448 "MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x") at src/shared/log.c:750
#11 0x080590c5 in process_event (ev=0xbf85e8b8, m=<optimized out>) at src/core/manager.c:1729
#12 manager_loop (m=0x867d530) at src/core/manager.c:1854
#13 0x0804f3c0 in main (argc=1, argv=0xbf85edd4) at src/core/main.c:1651
(gdb) quit
Comment by Natrio (natrio) - Friday, 20 September 2013, 16:53 GMT
Sandy Bridge machine.
CPU:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Celeron(R) CPU G530 @ 2.40GHz
stepping : 7
microcode : 0x23

backtrace:
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/lib/systemd/systemd...Reading symbols from /usr/lib/debug/usr/lib/systemd/systemd.debug...done.
done.
[New LWP 679]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/sbin/init'.
Program terminated with signal 11, Segmentation fault.
#0 0xb7772424 in __kernel_vsyscall ()
[?1034h(gdb) bt
#0 0xb7772424 in __kernel_vsyscall ()
#1 0xb7698d76 in raise () from /usr/lib/libpthread.so.0
#2 0x08051778 in crash (sig=11) at src/core/main.c:143
#3 <signal handler called>
#4 0xb74f1390 in free@plt () from /usr/lib/libc.so.6
#5 0xb751e609 in vfprintf () from /usr/lib/libc.so.6
#6 0xb75d48e0 in __vsnprintf_chk () from /usr/lib/libc.so.6
#7 0xb75d4807 in __snprintf_chk () from /usr/lib/libc.so.6
#8 0x080b04e5 in snprintf (
__fmt=0x810e038 "PRIORITY=%i\nSYSLOG_FACILITY=%i\n%s%.*s%s%s%.*i%s%s%.*s%s%s%.*s%sSYSLOG_IDENTIFIER=%s\n", __n=2048, __s=0xbfca50cc "PRIORITY=6\nSYSLOG_FACILITY=3\nCODE_FILE=\267)")
at /usr/include/bits/stdio2.h:64
#9 log_do_header (
header=header@entry=0xbfca50cc "PRIORITY=6\nSYSLOG_FACILITY=3\nCODE_FILE=\267)",
level=level@entry=30, file=file@entry=0x80dc52e "src/core/manager.c", line=line@entry=1732,
func=func@entry=0x80ddd36 <__func__.12811> "process_event", object_name=object_name@entry=0x0,
object=object@entry=0x0, size=2048) at src/shared/log.c:445
#10 0x080b1c69 in log_struct_internal (level=30, level@entry=6,
file=file@entry=0x80dc52e "src/core/manager.c", line=line@entry=1732,
func=func@entry=0x80ddd36 <__func__.12811> "process_event",
format=format@entry=0x80dd448 "MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x") at src/shared/log.c:750
#11 0x080590c5 in process_event (ev=0xbfca5988, m=<optimized out>) at src/core/manager.c:1729
#12 manager_loop (m=0x9f28530) at src/core/manager.c:1854
#13 0x0804f3c0 in main (argc=1, argv=0xbfca5ea4) at src/core/main.c:1651
(gdb) quit
Comment by Dave Reisner (falconindy) - Friday, 20 September 2013, 18:45 GMT
Nothing really to do here -- it's memory corruption which could be the result of a kernel bug.

How are you suspending? Do you have any hooks which might unload/load modules or do anything else?
Comment by Dave Reisner (falconindy) - Friday, 20 September 2013, 18:52 GMT
According to https://bbs.archlinux.org/viewtopic.php?pid=1327084 this has nothing to with systemd 207, and everything to do with linux 3.11.x. So, my suggestion that this is memory corruption due to a kernel bug seems accurate.

Take it to the kernel bugzilla.

Loading...