Hi!
In SLES15 SP3 I have found some interesting fact about systemd-coredump:
A process dumped core for strange reasons (investigated by support), and the
journal had logged:
Mar 04 07:20:02 h19 systemd-coredump[27340]: Process 27338 (sh) of user 0
dumped core.
Stack trace of thread 27338:
#0 0x00007fdd7418a938
locked_vfxprintf (libc.so.6 + 0x84938)
#1 0x00007fdd7418ab55
__vfxprintf (libc.so.6 + 0x84b55)
#2 0x00007fdd7418acb6
__fxprintf (libc.so.6 + 0x84cb6)
#3 0x00007fdd7419eb40
__malloc_assert (libc.so.6 + 0x98b40)
#4 0x00007fdd741a1583
sysmalloc (libc.so.6 + 0x9b583)
...I'm leaving out the boring lines in between
#61 0x00007fdd7418ab55
__vfxprintf (libc.so.6 + 0x84b55)
#62 0x00007fdd7418acb6
__fxprintf (libc.so.6 + 0x84cb6)
#63 0x00007fdd7419eb40
__malloc_assert (libc.so.6 + 0x98b40)
Mar 04 07:20:02 h19 systemd[1]: [email protected]: Succeeded.
Mar 04 07:20:03 h19 kernel: BUG: Bad rss-counter state mm:00000000ba7a09bc
idx:1 val:16
However when examining the stack trace with gdb, the stack is horribly deep:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fdd7418a938 in locked_vfxprintf () from /lib64/libc.so.6
Missing separate debuginfos, use: zypper install
bash-debuginfo-4.4-19.6.1.x86_64
(gdb) bt
#0 0x00007fdd7418a938 in locked_vfxprintf () from /lib64/libc.so.6
#1 0x00007fdd7418ab55 in __vfxprintf () from /lib64/libc.so.6
#2 0x00007fdd7418acb6 in __fxprintf () from /lib64/libc.so.6
#3 0x00007fdd7419eb40 in __malloc_assert () from /lib64/libc.so.6
#4 0x00007fdd741a1583 in sysmalloc () from /lib64/libc.so.6
#5 0x00007fdd741a2380 in _int_malloc () from /lib64/libc.so.6
...
#39520 0x00007fdd741a1583 in sysmalloc () from /lib64/libc.so.6
#39521 0x00007fdd741a2380 in _int_malloc () from /lib64/libc.so.6
#39522 0x00007fdd741a34f4 in malloc () from /lib64/libc.so.6
#39523 0x000055f1048cf52e in xmalloc ()
#39524 0x000055f1048d9521 in strvec_from_word_list ()
#39525 0x000055f1048acb31 in ?? ()
#39526 0x000055f1048aa56d in execute_command_internal ()
#39527 0x000055f1048d0836 in parse_and_execute ()
#39528 0x000055f1048c69ef in command_substitute ()
#39529 0x000055f1048c212f in ?? ()
#39530 0x000055f1048bd620 in ?? ()
#39531 0x000055f1048bf2ab in ?? ()
#39532 0x000055f1048ab955 in ?? ()
#39533 0x000055f1048aa56d in execute_command_internal ()
#39534 0x000055f1048d0836 in parse_and_execute ()
#39535 0x000055f1048da695 in ?? ()
#39536 0x000055f10489f786 in main ()
So my proposal would be to indicate that the stack dump is incomplete, maybe
also leaving out the middle part as I did in gdb.
Regards,
Ulrich
