Public issue detail

Runaway CPU investigation for java: futex lock contention at libjvm.so [.] void OopOopIterateDispatch<G1CMOopClosure>::Table::oop_oo…

java is stuck in a likely futex lock contention loop: 9.37% of sampled CPU passed through libjvm.so [.] void OopOopIterateDispatch<G1CMOopClosure>::Tab..., with repeated thread backtraces show 10 thread(s) around 0x00007f11a21bb9ee in futex_fatal_error () from target:<path> and 5 thread(s) around 0x00007f11a21bb9ee in futex_fatal_error () from target:<path>.

highscore: 106reports: 1

Last seen: 2026-10-01 09:50 UTC. Public JSON: /v1/issues/01a0f512-f215-7b72-9dda-8c0d3032c197

Technical snapshot

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

Representative thread backtrace

  • Command: /woodpecker/src/gitea.osgeo.org/postgis/postgis/.tmp/codeql/codeql/tools/linux64/java/bin/java -Dsun.misc.unsafe.memory.access=allow -Xmx1154M -Dcodeql.chainer.v2=/tmp/codeql.np9Bg1su --add-modules jdk.unsupported -cp /woodpecker/src/gitea.osgeo.org/postgis/postgis/.tmp/codeql/codeql/tools/codeql.jar com.semmle.cli2.CodeQL env_argv execute queries -J-Xmx1154M _ _ _ _ _ _ _ --no-rerun _ _ -- /woodpecker/src/gitea.osgeo.org/postgis/postgis/.tmp/codeql/db/db-cpp cpp-security-and-quality.qls
  • Why Fixer classified it this way: Multiple captured threads converge on futex or pthread mutex paths, which suggests user-space lock contention or a lock convoy.
  • Thread summary: thread backtraces show 10 thread(s) around 0x00007f11a21bb9ee in futex_fatal_error () from target:<path> and 5 thread(s) around 0x00007f11a21bb9ee in futex_fatal_error () from target:<path>
  • Contention signals: futex-lock-contention, allocator-contention, 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. warning: Expected absolute pathname for libpthread in the inferior, but got target:<path> warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
  • Repeated loop: getrusage -> getrusage -> getrusage
  • Top syscalls: getrusage x28597, write x4874, futex x3615, lseek x2771
  • Kernel: 7.1.8+deb14.1-amd64
  • Distribution: debian
0x00007f11a21bb9ee in futex_fatal_error () from target:<path>
0x00007f11a21b0668 in __GI__IO_flush_all () from target:<path>
0x00007f11a21b0c8c in _IO_unbuffer_all () from target:<path>
0x00007f11a21b3158 in pthread_cond_wait () from target:<path>
0x00007f11a168f723 in Parker::park(bool, long) () from target:<path>
0x00007f11a1a48830 in Unsafe_Park () from target:<path>
0x00007f1192d7da72 in ?? ()
0x00000000b8001050 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 java: futex lock contention at libjvm.so [.] void OopOopIterateDispatch<G1MarkAndPushClosure>::Table::…

possible duplicate

java is stuck in a likely futex lock contention loop: 11.06% of sampled CPU passed through libjvm.so [.] void OopOopIterateDispatch<G1MarkAndPushClosure..., with repeated thread backtraces show 10 thread(s) around 0x00007fae649049ee in futex_fatal_error () from target:<path> and 6 thread(s) around 0x00007fae649049ee in futex_fatal_error () from target:<path>.

highscore: 106reports: 1similarity: 99%

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

Last seen: 2026-10-02 10:53 UTC. Public page: /issues/01a0d837-717d-7fb2-8448-57365f123bff. Public JSON: /v1/issues/01a0d837-717d-7fb2-8448-57365f123bff

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.