Public issue detail

Runaway CPU investigation for git: unknown userspace loop at adler32_z

git is stuck in a likely unclassified userspace loop: 5.95% of sampled CPU passed through adler32_z, with repeated thread backtraces show 1 thread(s) around 0x00007f9b54a5bdbb in ?? () from target:<path> and 1 thread(s) around 0x00007f9b54a5bdbb in ?? () from target:<path>.

highpackage: gitsource: gitscore: 106reports: 1

Last seen: 2026-10-03 03:35 UTC. Public JSON: /v1/issues/019f77a0-05b9-7551-9a82-40564740cf6d

Technical snapshot

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

Representative thread backtrace

  • Command: git fetch --no-tags origin +49125e9c2f0950499e0df34a3b2807ebe0d59f11:
  • Why Fixer classified it this way: The process is demonstrably CPU-hot, but the current syscall and symbol sample does not point to a single dominant loop family yet.
  • Thread summary: thread backtraces show 1 thread(s) around 0x00007f9b54a5bdbb in ?? () from target:<path> and 1 thread(s) around 0x00007f9b54a5bdbb in ?? () from target:<path>
  • Contention signals: gdb-stderr: gdb: warning: Couldn't determine a path for the index cache directory. warning: Target and debugger are in different PID namespaces; thread lists and other data are likely unreliable. Connect to gdbserver inside the container.
  • Repeated loop: read -> read -> read
  • Top syscalls: read x474, write x122, <... read resumed>, "\260 x1
  • Package: git 1:2.55.0-1
  • Kernel: 7.1.8+deb14.1-amd64
  • Distribution: debian
0x00007f9b54a5bdbb in ?? () from target:<path>
0x00007f9b54a5972f in ?? () from target:<path>
0x00007f9b54a98b64 in ?? () from target:<path>
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 x86_64-linux-gnu-ld.bfd: unknown userspace loop at bfd_hash_lookup

possible duplicate

x86_64-linux-gnu-ld.bfd is stuck in a likely unclassified userspace loop: 20.88% of sampled CPU passed through bfd_hash_lookup, with repeated thread backtraces show 1 thread(s) around 0x00007f3e33f25687 in __GI__IO_flush_all () from target:<path>.

highpackage: binutils-x86-64-linux-gnusource: binutilsscore: 106reports: 1similarity: 75%

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

Last seen: 2026-10-02 08:58 UTC. Public page: /issues/01a0fbd5-dd14-7700-8fc7-e7f71eb95e13. Public JSON: /v1/issues/01a0fbd5-dd14-7700-8fc7-e7f71eb95e13

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.