Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #1153503 > unrolled thread
| Started by | Aurelien Jarno <aurelien@aurel32.net> |
|---|---|
| First post | 2023-07-09 23:40 +0200 |
| Last post | 2023-07-11 22:40 +0200 |
| Articles | 11 — 2 participants |
Back to article view | Back to linux.debian.bugs.dist
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Bug#1040716: libc6: Stack Traces Aurelien Jarno <aurelien@aurel32.net> - 2023-07-09 23:40 +0200
Bug#1040716: libc6: Stack Traces Tim McConnell <tmcconnell168@gmail.com> - 2023-07-10 00:20 +0200
Bug#1040716: libc6: Stack Traces Aurelien Jarno <aurelien@aurel32.net> - 2023-07-10 23:30 +0200
Bug#1040716: libc6: Stack Traces Tim McConnell <tmcconnell168@gmail.com> - 2023-07-11 02:30 +0200
Bug#1040716: libc6: Stack Traces Tim McConnell <tmcconnell168@gmail.com> - 2023-07-11 02:40 +0200
Bug#1040716: libc6: Stack Traces Tim McConnell <tmcconnell168@gmail.com> - 2023-07-11 18:30 +0200
Bug#1040716: libc6: Stack Traces Aurelien Jarno <aurelien@aurel32.net> - 2023-07-11 21:20 +0200
Bug#1040716: libc6: Stack Traces Aurelien Jarno <aurelien@aurel32.net> - 2023-07-11 22:40 +0200
Bug#1040716: libc6: Stack Traces Tim McConnell <tmcconnell168@gmail.com> - 2023-07-11 23:00 +0200
Bug#1040716: libc6: crashes with SIGBUS in rrd_write Aurelien Jarno <aurelien@aurel32.net> - 2023-07-12 21:00 +0200
Bug#1040716: libc6: Stack Traces Tim McConnell <tmcconnell168@gmail.com> - 2023-07-11 22:40 +0200
| From | Aurelien Jarno <aurelien@aurel32.net> |
|---|---|
| Date | 2023-07-09 23:40 +0200 |
| Subject | Bug#1040716: libc6: Stack Traces |
| Message-ID | <GPKil-47t9-11@gated-at.bofh.it> |
Hi, On 2023-07-09 15:05, Tim McConnell wrote: > Package: libc6 > Version: 2.37-3 > Severity: normal > Thanks for your bug report. Could you please explain me what are those stack traces, and what is the issue you encountered? Thanks. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://aurel32.net
[toc] | [next] | [standalone]
| From | Tim McConnell <tmcconnell168@gmail.com> |
|---|---|
| Date | 2023-07-10 00:20 +0200 |
| Message-ID | <GPKV3-47VB-3@gated-at.bofh.it> |
| In reply to | #1153503 |
Hi Aurelien, The Stack Traces started showing up in my System Event logs yesterday and has totaled up to 18 times so far. As far as issues, the system is slower than usual and occasionally freezes. I ran apt-file search lib.so and came up with libc6 so that's where I filed the bug. I tried running gdb on it (libc6) and it told me file not found, I'd be happy to give more information just tell me how to get it. -- Tim McConnell <tmcconnell168@gmail.com> On Sun, 2023-07-09 at 23:34 +0200, Aurelien Jarno wrote: > Hi, > > On 2023-07-09 15:05, Tim McConnell wrote: > > Package: libc6 > > Version: 2.37-3 > > Severity: normal > > > > Thanks for your bug report. Could you please explain me what are > those > stack traces, and what is the issue you encountered? Thanks. > > Regards > Aurelien >
[toc] | [prev] | [next] | [standalone]
| From | Aurelien Jarno <aurelien@aurel32.net> |
|---|---|
| Date | 2023-07-10 23:30 +0200 |
| Message-ID | <GQ6Cd-4lqv-7@gated-at.bofh.it> |
| In reply to | #1153511 |
Hi, On 2023-07-09 17:15, Tim McConnell wrote: > Hi Aurelien, > The Stack Traces started showing up in my System Event logs yesterday > and has totaled up to 18 times so far. As far as issues, the system is > slower than usual and occasionally freezes. > I ran apt-file search lib.so and came up with libc6 so that's where I > filed the bug. I tried running gdb on it (libc6) and it told me file > not found, I'd be happy to give more information just tell me how to > get it. Thanks for the details, however I am afraid it is not enough. libc6 is a library, for understanding the issue, I would need to know by which program it is used in the corresponding stack traces. The issue might not be in the library but in another library or another program. Do you have some more log entries around those stack traces? All that said, it appears that the locales package in versions 2.37-2 to 2.37-4 is buggy and might cause random crashes in libc6. You might want to upgrade to version 2.37-5 to check if it solves your issue. The package is currently only available in sid, but it is expected to migrate to testing in the next days. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://aurel32.net
[toc] | [prev] | [next] | [standalone]
| From | Tim McConnell <tmcconnell168@gmail.com> |
|---|---|
| Date | 2023-07-11 02:30 +0200 |
| Message-ID | <GQ9qp-4n4I-1@gated-at.bofh.it> |
| In reply to | #1153642 |
On Mon, 2023-07-10 at 23:17 +0200, Aurelien Jarno wrote: > Hi, > > On 2023-07-09 17:15, Tim McConnell wrote: > > Hi Aurelien, > > The Stack Traces started showing up in my System Event logs > > yesterday > > and has totaled up to 18 times so far. As far as issues, the system > > is > > slower than usual and occasionally freezes. > > I ran apt-file search lib.so and came up with libc6 so that's > > where I > > filed the bug. I tried running gdb on it (libc6) and it told me > > file > > not found, I'd be happy to give more information just tell me how > > to > > get it. > > Thanks for the details, however I am afraid it is not enough. libc6 > is a > library, for understanding the issue, I would need to know by which > program it is used in the corresponding stack traces. The issue might > not be in the library but in another library or another program. Do > you > have some more log entries around those stack traces? > > All that said, it appears that the locales package in versions 2.37-2 > to > 2.37-4 is buggy and might cause random crashes in libc6. You might > want > to upgrade to version 2.37-5 to check if it solves your issue. The > package is currently only available in sid, but it is expected to > migrate to testing in the next days. > > Regards > Aurelien > I'll check journalctl and see if that has better info. I'll also upgrade the package you were talking about to see if it fixes the issue . I will let you know.
[toc] | [prev] | [next] | [standalone]
| From | Tim McConnell <tmcconnell168@gmail.com> |
|---|---|
| Date | 2023-07-11 02:40 +0200 |
| Message-ID | <GQ9A5-4n7I-3@gated-at.bofh.it> |
| In reply to | #1153642 |
On Mon, 2023-07-10 at 23:17 +0200, Aurelien Jarno wrote:
> Hi,
>
> On 2023-07-09 17:15, Tim McConnell wrote:
> > Hi Aurelien,
> > The Stack Traces started showing up in my System Event logs
> > yesterday
> > and has totaled up to 18 times so far. As far as issues, the system
> > is
> > slower than usual and occasionally freezes.
> > I ran apt-file search lib.so and came up with libc6 so that's
> > where I
> > filed the bug. I tried running gdb on it (libc6) and it told me
> > file
> > not found, I'd be happy to give more information just tell me how
> > to
> > get it.
>
> Thanks for the details, however I am afraid it is not enough. libc6
> is a
> library, for understanding the issue, I would need to know by which
> program it is used in the corresponding stack traces. The issue might
> not be in the library but in another library or another program. Do
> you
> have some more log entries around those stack traces?
>
> All that said, it appears that the locales package in versions 2.37-2
> to
> 2.37-4 is buggy and might cause random crashes in libc6. You might
> want
> to upgrade to version 2.37-5 to check if it solves your issue. The
> package is currently only available in sid, but it is expected to
> migrate to testing in the next days.
>
> Regards
> Aurelien
>
Checking Journalctl I found this:
Jul 10 19:02:11 DebianTim systemd-coredump[3869]: [🡕] Process 992
(collectd) of user 0 dumped core.
Module libudev.so.1
from deb systemd-252.11-1.amd64
Stack trace of thread
1424:
#0
0x00007f7cbbfce9f2 __memmove_ssse3 (libc.so.6 + 0x16d9f2)
#1
0x00007f7cbbd856d9 rrd_write (librrd.so.8 + 0x346d9)
#2
0x00007f7cbbd90acd n/a (librrd.so.8 + 0x3facd)
#3
0x00007f7cbbd92962 n/a (librrd.so.8 + 0x41962)
#4
0x00007f7cbbdec370 n/a (rrdtool.so + 0x3370)
#5
0x00007f7cbbee93ec start_thread (libc.so.6 + 0x883ec)
#6
0x00007f7cbbf69a1c __clone3 (libc.so.6 + 0x108a1c)
Stack trace of thread
1431:
#0
0x00007f7cbbee6156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007f7cbbee8afc __pthread_cond_wait_common (libc.so.6 + 0x87afc)
#2
0x00005586e89f93a2 n/a (collectd + 0x123a2)
#3
0x00007f7cbbee93ec start_thread (libc.so.6 + 0x883ec)
#4
0x00007f7cbbf69a1c __clone3 (libc.so.6 + 0x108a1c)
Stack trace of thread
1432:
#0
0x00007f7cbbee6156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007f7cbbee8afc __pthread_cond_wait_common (libc.so.6 + 0x87afc)
#2
0x00005586e89f93a2 n/a (collectd + 0x123a2)
#3
0x00007f7cbbee93ec start_thread (libc.so.6 + 0x883ec)
#4
0x00007f7cbbf69a1c __clone3 (libc.so.6 + 0x108a1c)
Stack trace of thread
1427:
#0
0x00007f7cbbee6156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007f7cbbee8818 __pthread_cond_wait_common (libc.so.6 + 0x87818)
#2
0x00005586e89f7d1b n/a (collectd + 0x10d1b)
#3
0x00007f7cbbee93ec start_thread (libc.so.6 + 0x883ec)
#4
0x00007f7cbbf69a1c __clone3 (libc.so.6 + 0x108a1c)
Stack trace of thread
1429:
#0
0x00007f7cbbee6156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007f7cbbee8818 __pthread_cond_wait_common (libc.so.6 + 0x87818)
#2
0x00005586e89f7d1b n/a (collectd + 0x10d1b)
Stack trace of thread
1425:
#0
0x00007f7cbbee6156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007f7cbbee8818 __pthread_cond_wait_common (libc.so.6 + 0x87818)
#2
0x00005586e89f7d1b n/a (collectd + 0x10d1b)
#3
0x00007f7cbbee93ec start_thread (libc.so.6 + 0x883ec)
#4
0x00007f7cbbf69a1c __clone3 (libc.so.6 + 0x108a1c)
Stack trace of thread
1434:
#0
0x00007f7cbbee6156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007f7cbbee8afc __pthread_cond_wait_common (libc.so.6 + 0x87afc)
#2
0x00005586e89f93a2 n/a (collectd + 0x123a2)
#3
0x00007f7cbbee93ec start_thread (libc.so.6 + 0x883ec)
#4
0x00007f7cbbf69a1c __clone3 (libc.so.6 + 0x108a1c)
I don't know if that is of anymore help or not.
[toc] | [prev] | [next] | [standalone]
| From | Tim McConnell <tmcconnell168@gmail.com> |
|---|---|
| Date | 2023-07-11 18:30 +0200 |
| Message-ID | <GQops-uX-11@gated-at.bofh.it> |
| In reply to | #1153642 |
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)
Stack trace of
thread 616847:
#0
0x00007fce132bfa25 __GI___clock_nanosleep (libc.so.6 + 0xcea25)
#1
0x00007fce132c43f3 __GI___nanosleep (libc.so.6 + 0xd33f3)
#2
0x000055ade3cad16b n/a (collectd + 0x816b)
#3
0x000055ade3cad7a8 run_loop (collectd + 0x87a8)
#4
0x000055ade3cac934 main (collectd + 0x7934)
#5
0x00007fce132186ca __libc_start_call_main (libc.so.6 + 0x276ca)
#6
0x00007fce13218785 __libc_start_main_impl (libc.so.6 + 0x27785)
#7
0x000055ade3cace21 _start (collectd + 0x7e21)
Stack trace of
thread 616849:
#0
0x00007fce13276156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007fce13278818 __pthread_cond_wait_common (libc.so.6 + 0x87818)
#2
0x000055ade3cb5d1b n/a (collectd + 0x10d1b)
#3
0x00007fce132793ec start_thread (libc.so.6 + 0x883ec)
#4
0x00007fce132f9a1c __clone3 (libc.so.6 + 0x108a1c)
Stack trace of
thread 616850:
#0
0x00007fce13276156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007fce13278818 __pthread_cond_wait_common (libc.so.6 + 0x87818)
#2
0x000055ade3cb5d1b n/a (collectd + 0x10d1b)
#3
0x00007fce132793ec start_thread (libc.so.6 + 0x883ec)
#4
0x00007fce132f9a1c __clone3 (libc.so.6 + 0x108a1c)
Stack trace of
thread 616851:
#0
0x00007fce13276156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007fce13278818 __pthread_cond_wait_common (libc.so.6 + 0x87818)
#2
0x000055ade3cb5d1b n/a (collectd + 0x10d1b)
#3
0x00007fce132793ec start_thread (libc.so.6 + 0x883ec)
#4
0x00007fce132f9a1c __clone3 (libc.so.6 + 0x108a1c)
Stack trace of
thread 616852:
#0
0x00007fce13276156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007fce13278818 __pthread_cond_wait_common (libc.so.6 + 0x87818)
#2
0x000055ade3cb5d1b n/a (collectd + 0x10d1b)
#3
0x00007fce132793ec start_thread (libc.so.6 + 0x883ec)
#4
0x00007fce132f9a1c __clone3 (libc.so.6 + 0x108a1c)
Stack trace of
thread 616853:
#0
0x00007fce13276156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007fce13278818 __pthread_cond_wait_common (libc.so.6 + 0x87818)
#2
0x000055ade3cb5d1b n/a (collectd + 0x10d1b)
#3
0x00007fce132793ec start_thread (libc.so.6 + 0x883ec)
#4
0x00007fce132f9a1c __clone3 (libc.so.6 + 0x108a1c)
Stack trace of
thread 616854:
#0
0x00007fce13276156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007fce13278afc __pthread_cond_wait_common (libc.so.6 + 0x87afc)
#2
0x000055ade3cb73a2 n/a (collectd + 0x123a2)
#3
0x00007fce132793ec start_thread (libc.so.6 + 0x883ec)
#4
0x00007fce132f9a1c __clone3 (libc.so.6 + 0x108a1c)
Stack trace of
thread 616855:
#0
0x00007fce13276156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007fce13278afc __pthread_cond_wait_common (libc.so.6 + 0x87afc)
#2
0x000055ade3cb73a2 n/a (collectd + 0x123a2)
#3
0x00007fce132793ec start_thread (libc.so.6 + 0x883ec)
#4
0x00007fce132f9a1c __clone3 (libc.so.6 + 0x108a1c)
Stack trace of
thread 616856:
#0
0x00007fce13276156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007fce13278afc __pthread_cond_wait_common (libc.so.6 + 0x87afc)
#2
0x000055ade3cb73a2 n/a (collectd + 0x123a2)
#3
0x00007fce132793ec start_thread (libc.so.6 + 0x883ec)
#4
0x00007fce132f9a1c __clone3 (libc.so.6 + 0x108a1c)
Stack trace of
thread 616858:
#0
0x00007fce13276156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007fce13278afc __pthread_cond_wait_common (libc.so.6 + 0x87afc)
#2
0x000055ade3cb73a2 n/a (collectd + 0x123a2)
#3
0x00007fce132793ec start_thread (libc.so.6 + 0x883ec)
#4
0x00007fce132f9a1c __clone3 (libc.so.6 + 0x108a1c)
Stack trace of
thread 616857:
#0
0x00007fce13276156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
#1
0x00007fce13278afc __pthread_cond_wait_common (libc.so.6 + 0x87afc)
#2
0x000055ade3cb73a2 n/a (collectd + 0x123a2)
#3
0x00007fce132793ec start_thread (libc.so.6 + 0x883ec)
#4
0x00007fce132f9a1c __clone3 (libc.so.6 + 0x108a1c)
ELF object binary
architecture: AMD x86-64
Jul 11 10:52:06 DebianTim systemd[1]: collectd.service: Main process
exited, code=dumped, status=7/BUS
Jul 11 10:52:06 DebianTim systemd[1]: collectd.service: Failed with
result 'core-dump'.
Jul 11 10:52:06 DebianTim systemd[1]:
systemd-coredump@1785-616863-0.service: Deactivated successfully.
[toc] | [prev] | [next] | [standalone]
| From | Aurelien Jarno <aurelien@aurel32.net> |
|---|---|
| Date | 2023-07-11 21:20 +0200 |
| Message-ID | <GQr3X-1nr-19@gated-at.bofh.it> |
| In reply to | #1153762 |
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
[toc] | [prev] | [next] | [standalone]
| From | Aurelien Jarno <aurelien@aurel32.net> |
|---|---|
| Date | 2023-07-11 22:40 +0200 |
| Message-ID | <GQsjo-244-15@gated-at.bofh.it> |
| In reply to | #1153784 |
Hi, On 2023-07-11 15:28, Tim McConnell wrote: > > > On Tue, 2023-07-11 at 21:11 +0200, Aurelien Jarno wrote: > > 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 > > > I'm unsure how helpful this is ( I am not a programmer) but: > thread apply all bt Thanks, that's already much more useful. However I forgot to tell you to install the libc6-dbg package before getting the backtrace, sorry about that. Could you please install it and follow the same procedure again? Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://aurel32.net
[toc] | [prev] | [next] | [standalone]
| From | Tim McConnell <tmcconnell168@gmail.com> |
|---|---|
| Date | 2023-07-11 23:00 +0200 |
| Message-ID | <GQsCJ-2bI-13@gated-at.bofh.it> |
| In reply to | #1153801 |
On Tue, 2023-07-11 at 22:34 +0200, Aurelien Jarno wrote: > Hi, > > On 2023-07-11 15:28, Tim McConnell wrote: > > > > > > On Tue, 2023-07-11 at 21:11 +0200, Aurelien Jarno wrote: > > > 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 > > > > > I'm unsure how helpful this is ( I am not a programmer) but: > > thread apply all bt > > Thanks, that's already much more useful. However I forgot to tell you > to > install the libc6-dbg package before getting the backtrace, sorry > about > that. Could you please install it and follow the same procedure > again? > > Thanks > Aurelien > It's already there, any others?
[toc] | [prev] | [next] | [standalone]
| From | Aurelien Jarno <aurelien@aurel32.net> |
|---|---|
| Date | 2023-07-12 21:00 +0200 |
| Subject | Bug#1040716: libc6: crashes with SIGBUS in rrd_write |
| Message-ID | <GQNea-eMt-1@gated-at.bofh.it> |
| In reply to | #1153820 |
control: reassign -1 librrd8
control: retitle -1 librrd8: crashes with SIGBUS in rrd_write
Hi,
On 2023-07-11 15:53, Tim McConnell wrote:
>
>
> On Tue, 2023-07-11 at 22:34 +0200, Aurelien Jarno wrote:
> > Hi,
> >
> > On 2023-07-11 15:28, Tim McConnell wrote:
> > >
> > >
> > > On Tue, 2023-07-11 at 21:11 +0200, Aurelien Jarno wrote:
> > > > 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
> > > >
> > > I'm unsure how helpful this is ( I am not a programmer) but:
> > > thread apply all bt
> >
> > Thanks, that's already much more useful. However I forgot to tell you
> > to
> > install the libc6-dbg package before getting the backtrace, sorry
> > about
> > that. Could you please install it and follow the same procedure
> > again?
> >
> > Thanks
> > Aurelien
> >
> It's already there, any others?
I was expecting to see the arguments of the glibc functions, but anyway
I have been able to understand the code path.
collectd uses the librrd8 library to handle data, which at some point
calls the glibc memmove function. The crashes (SIGBUS) happens in the
memmove function when trying to destination buffer:
| .p2align 4,, 4
| L(copy_0_15):
| cmpl $4, %edx
| jb L(copy_0_3)
| cmpl $8, %edx
| jb L(copy_4_7)
| movq 0(%rsi), %rcx
| movq -8(%rsi, %rdx), %rsi
=> movq %rcx, 0(%rdi)
| movq %rsi, -8(%rdi, %rdx)
| ret
memmove is called in
the rrd_write function, and more precisely in the memmove call:
| ssize_t rrd_write(
| rrd_file_t *rrd_file,
| const void *buf,
| size_t count)
| {
[...]
| #ifdef HAVE_MMAP
| size_t old_size = rrd_file->file_len;
|
| if (count == 0)
| return 0;
| if (buf == NULL)
| return -1; /* EINVAL */
|
| if ((rrd_file->pos + count) > old_size) {
| rrd_set_error
| ("attempting to write beyond end of file (%ld + %ld > %ld)",
| rrd_file->pos, count, old_size);
| return -1;
| }
| /* can't use memcpy since the areas overlap when tuning */
=> memmove(rrd_simple_file->file_start + rrd_file->pos, buf, count);
| rrd_file->pos += count;
| return count; /* mimic write() semantics */
librrd8 uses mmap to open the file, and then does a memmove on the
corresponding memory mapping. The fact it crashes with SIGBUS means that
a memory access is attempted beyond the end of the mapped file.
Therefore this is not an issue in glibc, but could be due to a corrupted
RRD file or a bug in the librrd8 library. Depending on the data you have
in the RRD files, you might want to recreate them to see if the issue
goes away or not.
In any case, I am reassigning the bug to the librrd8 package. The
librrd8 maintainers might have a better idea how to debug that further.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://aurel32.net
[toc] | [prev] | [next] | [standalone]
| From | Tim McConnell <tmcconnell168@gmail.com> |
|---|---|
| Date | 2023-07-11 22:40 +0200 |
| Message-ID | <GQsjo-244-17@gated-at.bofh.it> |
| In reply to | #1153784 |
On Tue, 2023-07-11 at 21:11 +0200, Aurelien Jarno wrote: > 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 > I'm unsure how helpful this is ( I am not a programmer) but: thread apply all bt Thread 12 (Thread 0x7fae021f96c0 (LWP 9783)): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x7fae021f8e60, op=393, expected=0, futex_word=0x556c7b80d488) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x556c7b80d488, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fae021f8e60, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex- internal.c:87 #2 0x00007fae08a3b1bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x556c7b80d488, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fae021f8e60, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007fae08a3dafc in __pthread_cond_wait_common (abstime=0x7fae021f8e60, clockid=0, mutex=0x556c7b80d4a0, cond=0x556c7b80d460) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_timedwait64 (cond=0x556c7b80d460, mutex=0x556c7b80d4a0, abstime=0x7fae021f8e60) at ./nptl/pthread_cond_wait.c:643 #5 0x0000556c7b7e83a2 in () #6 0x00007fae08a3e3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444 #7 0x00007fae08abea1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 11 (Thread 0x7fae08c1a740 (LWP 9776)): #0 0x00007fae08a84a25 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7fff754277f0, rem=0x7fff754277f0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48 #1 0x00007fae08a893f3 in __GI___nanosleep (req=<optimized out>, rem=<optimized out>) at ../sysdeps/unix/sysv/linux/nanosleep.c:25 #2 0x0000556c7b7de16b in () #3 0x0000556c7b7de7a8 in run_loop () #4 0x0000556c7b7dd934 in main () Thread 10 (Thread 0x7fae041fd6c0 (LWP 9779)): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x556c7b80d3e8) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x556c7b80d3e8, expected=expected@entry=0, clockid=clockid@entry=0, abst--Type <RET> for more, q to quit, c to continue without paging-- ime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex-internal.c:87 #2 0x00007fae08a3b1bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x556c7b80d3e8, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007fae08a3d818 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x556c7b80d400, cond=0x556c7b80d3c0) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=0x556c7b80d3c0, mutex=0x556c7b80d400) at ./nptl/pthread_cond_wait.c:618 #5 0x0000556c7b7e6d1b in () #6 0x00007fae08a3e3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444 #7 0x00007fae08abea1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 9 (Thread 0x7fae001f56c0 (LWP 9787)): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x7fae001f4e60, op=393, expected=0, futex_word=0x556c7b80d488) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x556c7b80d488, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fae001f4e60, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex- internal.c:87 #2 0x00007fae08a3b1bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x556c7b80d488, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fae001f4e60, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007fae08a3dafc in __pthread_cond_wait_common (abstime=0x7fae001f4e60, clockid=0, mutex=0x556c7b80d4a0, cond=0x556c7b80d460) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_timedwait64 (cond=0x556c7b80d460, mutex=0x556c7b80d4a0, abstime=0x7fae001f4e60) at ./nptl/pthread_cond_wait.c:643 #5 0x0000556c7b7e83a2 in () #6 0x00007fae08a3e3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444 #7 0x00007fae08abea1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 8 (Thread 0x7fae009f66c0 (LWP 9786)): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x7fae009f5e60, op=393, expected=0, futex_word=0x556c7b80d488) at ./nptl/futex-internal.c:57 --Type <RET> for more, q to quit, c to continue without paging-- #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x556c7b80d488, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fae009f5e60, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex- internal.c:87 #2 0x00007fae08a3b1bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x556c7b80d488, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fae009f5e60, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007fae08a3dafc in __pthread_cond_wait_common (abstime=0x7fae009f5e60, clockid=0, mutex=0x556c7b80d4a0, cond=0x556c7b80d460) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_timedwait64 (cond=0x556c7b80d460, mutex=0x556c7b80d4a0, abstime=0x7fae009f5e60) at ./nptl/pthread_cond_wait.c:643 #5 0x0000556c7b7e83a2 in () #6 0x00007fae08a3e3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444 #7 0x00007fae08abea1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 7 (Thread 0x7fae011f76c0 (LWP 9785)): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x7fae011f6e60, op=393, expected=0, futex_word=0x556c7b80d488) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x556c7b80d488, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fae011f6e60, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex- internal.c:87 #2 0x00007fae08a3b1bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x556c7b80d488, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fae011f6e60, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007fae08a3dafc in __pthread_cond_wait_common (abstime=0x7fae011f6e60, clockid=0, mutex=0x556c7b80d4a0, cond=0x556c7b80d460) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_timedwait64 (cond=0x556c7b80d460, mutex=0x556c7b80d4a0, abstime=0x7fae011f6e60) at ./nptl/pthread_cond_wait.c:643 #5 0x0000556c7b7e83a2 in () #6 0x00007fae08a3e3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444 #7 0x00007fae08abea1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 6 (Thread 0x7fae019f86c0 (LWP 9784)): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x7fae019f7e60, op=393, expected=0, futex_word=0x556c7b80d488) at --Type <RET> for more, q to quit, c to continue without paging-- ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x556c7b80d488, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fae019f7e60, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex- internal.c:87 #2 0x00007fae08a3b1bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x556c7b80d488, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fae019f7e60, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007fae08a3dafc in __pthread_cond_wait_common (abstime=0x7fae019f7e60, clockid=0, mutex=0x556c7b80d4a0, cond=0x556c7b80d460) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_timedwait64 (cond=0x556c7b80d460, mutex=0x556c7b80d4a0, abstime=0x7fae019f7e60) at ./nptl/pthread_cond_wait.c:643 #5 0x0000556c7b7e83a2 in () #6 0x00007fae08a3e3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444 #7 0x00007fae08abea1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 5 (Thread 0x7fae029fa6c0 (LWP 9782)): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x556c7b80d3ec) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x556c7b80d3ec, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex- internal.c:87 #2 0x00007fae08a3b1bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x556c7b80d3ec, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007fae08a3d818 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x556c7b80d400, cond=0x556c7b80d3c0) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=0x556c7b80d3c0, mutex=0x556c7b80d400) at ./nptl/pthread_cond_wait.c:618 #5 0x0000556c7b7e6d1b in () #6 0x00007fae08a3e3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444 #7 0x00007fae08abea1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 4 (Thread 0x7fae031fb6c0 (LWP 9781)): --Type <RET> for more, q to quit, c to continue without paging-- #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x556c7b80d3e8) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x556c7b80d3e8, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex- internal.c:87 #2 0x00007fae08a3b1bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x556c7b80d3e8, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007fae08a3d818 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x556c7b80d400, cond=0x556c7b80d3c0) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=0x556c7b80d3c0, mutex=0x556c7b80d400) at ./nptl/pthread_cond_wait.c:618 #5 0x0000556c7b7e6d1b in () #6 0x00007fae08a3e3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444 #7 0x00007fae08abea1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 3 (Thread 0x7fae039fc6c0 (LWP 9780)): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x556c7b80d3ec) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x556c7b80d3ec, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex- internal.c:87 #2 0x00007fae08a3b1bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x556c7b80d3ec, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007fae08a3d818 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x556c7b80d400, cond=0x556c7b80d3c0) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=0x556c7b80d3c0, mutex=0x556c7b80d400) at ./nptl/pthread_cond_wait.c:618 #5 0x0000556c7b7e6d1b in () #6 0x00007fae08a3e3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444 #7 0x00007fae08abea1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 --Type <RET> for more, q to quit, c to continue without paging-- Thread 2 (Thread 0x7fae049fe6c0 (LWP 9778)): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x556c7b80d3ec) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x556c7b80d3ec, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex- internal.c:87 #2 0x00007fae08a3b1bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x556c7b80d3ec, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007fae08a3d818 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x556c7b80d400, cond=0x556c7b80d3c0) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=0x556c7b80d3c0, mutex=0x556c7b80d400) at ./nptl/pthread_cond_wait.c:618 #5 0x0000556c7b7e6d1b in () #6 0x00007fae08a3e3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444 #7 0x00007fae08abea1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 1 (Thread 0x7fae051ff6c0 (LWP 9777)): #0 __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memmove-ssse3.S:84 #1 0x00007fae088da6d9 in rrd_write () at /lib/x86_64-linux- gnu/librrd.so.8 #2 0x00007fae088e5acd in () at /lib/x86_64-linux-gnu/librrd.so.8 #3 0x00007fae088e7962 in () at /lib/x86_64-linux-gnu/librrd.so.8 #4 0x00007fae08941370 in () at /usr/lib/collectd/rrdtool.so #5 0x00007fae08a3e3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444 #6 0x00007fae08abea1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.bugs.dist
csiph-web