Public issue detail

Runaway CPU investigation for python3.13: unknown userspace loop at update_curr

python3.13 is stuck in a likely unclassified userspace loop: 7.01% of sampled CPU passed through update_curr, with repeated sched_yield x306829, futex x5952, lseek x3156.

highpackage: python3.13-minimalsource: python3.13score: 106reports: 1successful triage

Last seen: 2026-05-06 21:36 UTC. Public JSON: /v1/issues/019df9be-9d3c-79a2-90da-27fbaa284532

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-13 04:41 UTCvalidation: ready

python3.13 likely remains stuck in an unclassified userspace loop. Fixer produced a diagnosis report and intentionally skipped an automatic package patch attempt because the evidence is not specific enough to choose a safe source change.

Likely owner

external dependency or workload outside the current source tree

Reason: weak-unknown-runaway-evidence

Next steps

  • Confirm the hotspot still points at external dependency or workload outside the current source tree with a fresh perf sample before filing the bug.
  • Capture the actual hot backend or child process rather than the parent service wrapper if the issue recurs.
  • Map external dependency or workload outside the current source tree to its owning package or project and file an upstream or distro bug with the summarized evidence.
  • If the owner is still unclear, collect another short strace plus `/proc/<pid>/maps` at the moment of the spike.

Technical snapshot

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

Representative thread backtrace

  • Command: /home/<user>/.openclaw/venvs/panns-audio-tagging/bin/python /home/<user>/tasks-loop/src/scripts/rescore_acoustic_events.py --root /home/<user>/.openclaw/state/vigi_audio_events --model /home/<user>/.openclaw/state/vigi_audio_events/audio_event_kind_panns_teacher_v34.json --output-field machine_classification_teacher --hour-states /home/<user>/tasks-loop/Intermediate/info/hour_states.json
  • 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.
  • Wait site: 0
  • Hot path: update_curr (7.01% sampled CPU)
  • Repeated loop: sched_yield -> sched_yield -> sched_yield
  • Top syscalls: sched_yield x306829, futex x5952, lseek x3156, read x2009
  • Package: python3.13-minimal 3.13.12-1
  • Kernel: 6.17.10+deb14-amd64
  • Distribution: debian

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.

python3.13 is stuck in a likely busy poll loop: 13.20% of sampled CPU passed through unresolved offset, with repeated thread backtraces show 2 thread(s) around 0x00007ff1a4c7cffe in ?? () from target:<path> and 1 thread(s) around 0x0000000000557288 in ?? ().

highpackage: python3.13-minimalsource: python3.13score: 106reports: 2successful triagesimilarity: 70%

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

Last seen: 2026-06-10 00:32 UTC. Public page: /issues/019dd98b-0e1d-76e3-9171-f0f72c689536. Public JSON: /v1/issues/019dd98b-0e1d-76e3-9171-f0f72c689536

python3.13 is stuck in a likely busy poll loop: 100.00% of sampled CPU passed through dequeue_entity, with repeated thread backtraces show 1 thread(s) around 0x00007f1c6e7efe92 in pthread_attr_destroy () from target:<path>.

highpackage: python3.13-minimalsource: python3.13score: 106reports: 1similarity: 65%

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

Last seen: 2026-06-05 03:12 UTC. Public page: /issues/019e9114-5b91-76f3-b9b4-c11d578198d2. Public JSON: /v1/issues/019e9114-5b91-76f3-b9b4-c11d578198d2

python3.13 shows a repeated `D`-state wait, likely blocked in unknown uninterruptible wait via current_time.

highpackage: python3.13-minimalsource: python3.13score: 110reports: 1similarity: 53%

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

Last seen: 2026-05-06 23:10 UTC. Public page: /issues/019dff20-5e99-7871-8e0f-d0ff8b76b7aa. Public JSON: /v1/issues/019dff20-5e99-7871-8e0f-d0ff8b76b7aa

python3.13 shows a repeated `D`-state wait, likely blocked in unknown uninterruptible wait via an unknown wait point.

highpackage: python3.13-minimalsource: python3.13score: 110reports: 1similarity: 51%

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

Last seen: 2026-05-10 10:58 UTC. Public page: /issues/019dffa1-89c1-7d80-93a6-30e699eccb68. Public JSON: /v1/issues/019dffa1-89c1-7d80-93a6-30e699eccb68

python3.13 shows a repeated `D`-state wait, likely blocked in unknown uninterruptible wait via irqentry_exit_to_user_mode.

highpackage: python3.13-minimalsource: python3.13score: 110reports: 1similarity: 50%

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

Last seen: 2026-05-06 20:49 UTC. Public page: /issues/019dfe79-8d27-7c62-9c89-74399683f802. Public JSON: /v1/issues/019dfe79-8d27-7c62-9c89-74399683f802

Worker outcome summary

This issue has 1 recorded worker attempt. Only ready diffs and ready triage handoffs get dedicated public boards. Diagnosis-only reports and blocked attempts are summarized here so it is easier to see why work stalled.

1 ready triage handoffs

No ready patch attempts, diagnosis-only reports, failed patch attempts, explained impossible attempts, or other attempt states.

Most common blockers

  • weak-unknown-runaway-evidence (1 attempt)

Published attempts

ready triage handoff

triage

python3.13 likely remains stuck in an unclassified userspace loop. Fixer produced a diagnosis report and intentionally skipped an automatic package patch attempt because the evidence is not specific enough to choose a safe source change.

state: readycreated: 2026-05-13 04:41 UTCvalidation: ready

Why it stopped

weak-unknown-runaway-evidence

Handoff

Likely owner: external dependency or workload outside the current source tree

Reason: weak-unknown-runaway-evidence

  • Confirm the hotspot still points at external dependency or workload outside the current source tree with a fresh perf sample before filing the bug.
  • Capture the actual hot backend or child process rather than the parent service wrapper if the issue recurs.
  • Map external dependency or workload outside the current source tree to its owning package or project and file an upstream or distro bug with the summarized evidence.
  • If the owner is still unclear, collect another short strace plus `/proc/<pid>/maps` at the moment of the spike.