Public issue detail

Runaway CPU investigation for redis-check-rdb: busy poll at _dl_mcount_wrapper

redis-check-rdb is stuck in a likely busy poll loop: 7.02% of sampled CPU passed through _dl_mcount_wrapper, with repeated thread backtraces show 1 thread(s) around 0x00007f89688a74be in sem_trywait () and 1 thread(s) around 0x00007f89688a74be in sem_trywait ().

highpackage: redis-toolssource: redisscore: 106reports: 1

Last seen: 2026-07-09 22:57 UTC. Public JSON: /v1/issues/019f4885-4b06-73b1-b87b-845532d67d90

Technical snapshot

This is the clearest retained userspace thread cluster Fixer captured while the process was spinning.

Representative thread backtrace

  • Command: /usr/bin/redis-server 127.0.0.1:6379
  • Why Fixer classified it this way: The trace repeatedly returns to a poll-family syscall without meaningful blocking, which suggests a busy event-loop wakeup.
  • Thread summary: thread backtraces show 1 thread(s) around 0x00007f89688a74be in sem_trywait () and 1 thread(s) around 0x00007f89688a74be in sem_trywait ()
  • Contention signals: gdb-stderr: gdb: warning: Couldn't determine a path for the index cache directory. warning: "target:<path>": could not open as an executable file: Input<path> error. warning: `target:<path>': can't open to read symbols: Input<path> error. warning: Could not load vsyscall page because no executable was specified
  • Repeated loop: epoll_wait -> openat -> read
  • Top syscalls: epoll_wait x51, close x50, openat x50, read x50
  • Package: redis-tools 5:8.0.6-2
  • Kernel: 6.17.10+deb14-amd64
  • Distribution: debian
0x00007f89688a74be in sem_trywait ()
0x00007f896889bc84 in __libc_alloca_cutoff ()
0x00007f8969909348 in ?? ()
0x0000000000000000 in ?? ()

Possible duplicates

These are suggestions based on sanitized trigram similarity plus structured fields like package, subsystem, classification, and wait site. They are not auto-merged.

Runaway CPU investigation for redis-check-rdb: busy poll at unresolved offset in libjemalloc.so.2

possible duplicate

redis-check-rdb is stuck in a likely busy poll loop: 9.10% of sampled CPU passed through unresolved offset, with repeated thread backtraces show 1 thread(s) around 0x00007fbc72ca5ffe in ?? () and 1 thread(s) around 0x00007fbc72ca5ffe in ?? ().

highpackage: redis-toolssource: redisscore: 106reports: 2patch attempt readysimilarity: 99%

Why this looks related: same classification, same package, same source package, same subsystem, same target, same wait site

Last seen: 2026-07-10 03:06 UTC. Public page: /issues/019dd8e9-fd09-7ce2-ad17-85a44beba62d. Public JSON: /v1/issues/019dd8e9-fd09-7ce2-ad17-85a44beba62d

Runaway CPU investigation for redis-check-rdb: busy poll at unresolved offset in libc.so.6

possible duplicate

redis-check-rdb is stuck in a likely busy poll loop: 6.51% of sampled CPU passed through unresolved offset, with repeated thread backtraces show 1 thread(s) around 0x00007f89688a74be in ?? () and 1 thread(s) around 0x00007f89688a74be in ?? ().

highpackage: redis-toolssource: redisscore: 106reports: 2patch attempt readysimilarity: 99%

Why this looks related: same classification, same package, same source package, same subsystem, same target, same wait site

Last seen: 2026-07-09 13:37 UTC. Public page: /issues/019ddbca-7201-7d22-ba77-0c6c084821ee. Public JSON: /v1/issues/019ddbca-7201-7d22-ba77-0c6c084821ee

Runaway CPU investigation for redis-check-rdb: busy poll at pthread_mutex_trylock

possible duplicate

redis-check-rdb is stuck in a likely busy poll loop: 7.05% of sampled CPU passed through pthread_mutex_trylock, with repeated thread backtraces show 1 thread(s) around 0x00007f89688a74be in sem_trywait () and 1 thread(s) around 0x00007f89688a74be in sem_trywait ().

highpackage: redis-toolssource: redisscore: 106reports: 1similarity: 99%

Why this looks related: same classification, same package, same source package, same subsystem, same target, same wait site, very similar public summary

Last seen: 2026-07-10 02:05 UTC. Public page: /issues/019dd9db-4401-7352-a385-3fee52f27d28. Public JSON: /v1/issues/019dd9db-4401-7352-a385-3fee52f27d28

Runaway CPU investigation for redis-check-rdb: busy poll at update_curr

possible duplicate

redis-check-rdb is stuck in a likely busy poll loop: 4.80% of sampled CPU passed through update_curr, with repeated thread backtraces show 1 thread(s) around 0x00007f89688a74be in ?? () and 1 thread(s) around 0x00007f89688a74be in ?? ().

highpackage: redis-toolssource: redisscore: 106reports: 1similarity: 99%

Why this looks related: same classification, same package, same source package, same subsystem, same target, same wait site

Last seen: 2026-07-07 12:41 UTC. Public page: /issues/019f3c77-d8db-79f2-96d6-1595084d836f. Public JSON: /v1/issues/019f3c77-d8db-79f2-96d6-1595084d836f

Runaway CPU investigation for redis-check-rdb: dbus spin at unresolved offset in libc.so.6

possible duplicate

redis-check-rdb is stuck in a likely dbus spin loop: 7.11% of sampled CPU passed through unresolved offset, with repeated thread backtraces show 1 thread(s) around 0x00007fbc72ca5ffe in ?? () and 1 thread(s) around 0x00007fbc72ca5ffe in ?? ().

highpackage: redis-toolssource: redisscore: 106reports: 1similarity: 87%

Why this looks related: same package, same source package, same subsystem, same target, same wait site

Last seen: 2026-06-27 16:08 UTC. Public page: /issues/019f09b6-00ac-7ed1-b030-4d766182ca1e. Public JSON: /v1/issues/019f09b6-00ac-7ed1-b030-4d766182ca1e

Runaway CPU investigation for smtpd: busy poll at unix_maybe_add_creds

possible duplicate

smtpd is stuck in a likely busy poll loop: 14.11% of sampled CPU passed through unix_maybe_add_creds, with repeated thread backtraces show 1 thread(s) around 0x00007f529799e7d2 in ?? () from target:<path>.

highpackage: postfixsource: postfixscore: 106reports: 1similarity: 65%

Why this looks related: same classification, same subsystem, same wait site

Last seen: 2026-07-04 06:14 UTC. Public page: /issues/019ec5c3-2f99-7ea0-9bcc-7718d776a285. Public JSON: /v1/issues/019ec5c3-2f99-7ea0-9bcc-7718d776a285

Published attempts

No public attempts have been published for this issue yet.

Quarantine stays on by default so the public queue is harder to spam.