Public issue detail

Runaway CPU investigation for python3.11: busy poll at fput

python3.11 is stuck in a likely busy poll loop: 25.66% of sampled CPU passed through fput, with repeated thread backtraces show 24 thread(s) around 0x00007fcc05248f16 in ?? () from target:<path>.

highsource: linuxscore: 106reports: 1successful triage

Last seen: 2026-05-12 12:26 UTC. Public JSON: /v1/issues/019deedb-94f3-7283-b805-89912a5d531b

Successful triage

Fixer did not find an honest diff-backed change in this source tree. Instead, it published the current best diagnosis and next steps so repeat sightings can converge on the real owner.

best triagecreated: 2026-05-17 15:25 UTCvalidation: ready

python3.11 likely remains stuck in a busy-poll loop. A diagnosis report was created even though no patchable workspace was available: opportunity 90358 has no repo root, package name, or source package

Likely owner

the upstream maintainer

Reason: workspace-acquisition

Next steps

Review the package metadata and attach a source tree or upstream clone if one exists.
If no patchable tree is available, file an external bug using the diagnosis bundle.

Browse successful triage

Technical snapshot

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

Representative thread backtrace

Command: .venv/bin/python3 -m wyoming_faster_whisper --uri tcp://0.0.0.0:10300 --data-dir /data --uri tcp://0.0.0.0:10300 --model medium-int8 --language ru --device cuda --compute-type int8 --beam-size 3 --cpu-threads 8 --vad-filter --initial-prompt Привет. Хэй Джарвис. Включи свет. Выключи свет. Включи лайтстрип. Выключи лайтстрип. Световая лента. Lightstrip. LED strip. Свет в ванной. Ванная. Гостиная. Спальня. Который час? Как дела? --data-dir /data --download-dir /data
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 24 thread(s) around 0x00007fcc05248f16 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. 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: poll -> poll -> poll
Top syscalls: poll x50, futex x49, restart_syscall x5, <... restart_syscall resumed>) = -1 ETIMEDOUT x3
Kernel: 6.17.10+deb14-amd64
Distribution: debian

0x00007fcc05248f16 in ?? () from target:<path>
0x00007fcc0524b5d8 in pthread_cond_wait () from target:<path>
0x00007fcbfa68481b in blas_thread_server () from target:<path>
0x00007fcc0524c1f5 in ?? () from target:<path>
0x00007fcc052cbb40 in clone () from target:<path>

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 postgres: busy poll at xas_load

possible duplicate

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

highpackage: postgresql-18source: postgresql-18score: 106reports: 2patch attempt readysimilarity: 83%