Bug#1040716: libc6: Stack Traces
Hi,
On 2023-07-11 11:21, Tim McConnell wrote:
>
>
> On Mon, 2023-07-10 at 23:17 +0200, Aurelien Jarno wrote:
> > You might want
> > to upgrade to version 2.37-5 to check if it solves your issue
> Okay that's done and it's still doing it. The entry from Journalctl
> shows module libudev1 if that's of any use.
>
> Started systemd-coredump@1785-616863-0.service - Process Core Dump (PID
> 616863/UID 0).
> Jul 11 10:52:06 DebianTim systemd-coredump[616865]: Process 616847
> (collectd) of user 0 dumped core.
>
> Module libudev.so.1
> from deb systemd-252.11-1.amd64
> Stack trace of
> thread 616848:
> #0
> 0x00007fce1335e9f2 __memmove_ssse3 (libc.so.6 + 0x16d9f2)
> #1
> 0x00007fce131156d9 rrd_write (librrd.so.8 + 0x346d9)
> #2
> 0x00007fce13120acd n/a (librrd.so.8 + 0x3facd)
> #3
> 0x00007fce13122962 n/a (librrd.so.8 + 0x41962)
> #4
> 0x00007fce1317c370 n/a (rrdtool.so + 0x3370)
> #5
> 0x00007fce132793ec start_thread (libc.so.6 + 0x883ec)
> #6
> 0x00007fce132f9a1c __clone3 (libc.so.6 + 0x108a1c)
>
Thanks for the details. This shows that the binary crashing regularly is
collectd. This is very unlikely that the issue is linked to the locales,
and your test is confirming that.
It's also not clear that it's a glibc issue, it's more likely an issue
in collectd or librrd8. It appears that systemd-coredump saved a
coredump when the process crashed. You should be able do use
"coredumpctl" to get the list of cores. You can select one coredump and
examine it with gdb using "coredumpctl debug xxxx". Then when under gdb
you should be able to run "thread apply all bt" to get the backtrace.
That should allows to better understand the issue.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://aurel32.net
Reply to: