Incomplete call stack logged by systemd-coredump

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

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]: systemd-coredump@1-27339-0.service: 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