On Thu, Apr 17, 2025 at 04:24:18AM -0600, Liam Stitt wrote:
Hi. Since 10.0p1 came out, about half the time I try to connect to my
system it fails and on inspection there is a crash in the dmesg
output:
[419972.562415] sshd-session[189732]: segfault at 7ffceb533dbc ip
00007ff7dc95261d sp 00007ffceb533d70 error 6 in
libc.so.6[6261d,7ff7dc918000+165000] likely on CPU 3 (core 3, socket 0)
[419972.562422] Code: 59 ec ff ff e8 a4 a5 0b 00 0f 1f 40 00 41 57 49 89 f7 41 56 49
89 d6 41 55 41 54 55 53 48 89 fb 4c 89 ff 48 81 ec f8 04 00 00 <89> 4c 24 4c 48
89 74 24 70 be 25 00 00 00 64 48 8b 04 25 28 00 00
Of course the addresses and cpu number vary, but the code is always
the same.
Since this started happening a few days ago, I wondered if it might be
because my system had been up for over a year and cthulhu knows how
many versions of libc6 were still pinned in core because a process
still depended on it after an upgrade, but rebooting had no
effect. libc has also upgraded twice since this started, also with no
effect.
It won't be that, since a fresh sshd-session process is started each
time you connect.
Obviously this will require more investigation to debug. I am at your
disposal.
OK, so the log message just tells me that the crash in _IO_vfprintf,
which isn't very specific; we need to get a core dump. Assuming you're
running systemd, could you please:
* install the gdb and systemd-coredump packages
* get the crash to happen again
* run "sudo coredumpctl list" to check whether it's picked up the core
dump
* run "sudo DEBUGINFOD_URLS=https://debuginfod.debian.net/ coredumpctl
debug <pid>", where <pid> is the value in the PID column of
"coredumpctl list" corresponding to the process that crashed
* press "y" at the "Enable debuginfod for this session?" prompt
* type "bt" at the "(gdb)" prompt
* reply to this email with the output
There are other options if you aren't running systemd, but this is
probably the easiest to set up on a stock Debian system.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
