Public issue detail

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

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: 1

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

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.r4pyIO0Y --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 0x00007fae649049ee in futex_fatal_error () from target:<path> and 6 thread(s) around 0x00007fae649049ee 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 x17390, futex x3588, write x2213, read x1938
  • Kernel: 7.1.8+deb14.1-amd64
  • Distribution: debian
0x00007fae649049ee in futex_fatal_error () from target:<path>
0x00007fae648f9668 in __GI__IO_flush_all () from target:<path>
0x00007fae648f9c8c in _IO_unbuffer_all () from target:<path>
0x00007fae648fc158 in pthread_cond_wait () from target:<path>
0x00007fae63e8f723 in Parker::park(bool, long) () from target:<path>
0x00007fae64248830 in Unsafe_Park () from target:<path>
0x00007fae54b7c1f2 in ?? ()
0x00000000b8001200 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<G1CMOopClosure>::Table::oop_oo…

possible duplicate

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: 1similarity: 99%

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

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

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.