stablyai/orca · error · Error

Recorded benchmark helper PID now belongs to another process

Error message

Recorded benchmark helper PID now belongs to another process

What it means

signalProcessIdentity reads a recorded identity, validates it, then re-fetches the live identity by pid. If the pid is still alive but sameIdentity is false (pgid or command differs), the recorded helper has exited and the OS recycled its PID for an unrelated process. Signaling would hit the wrong process, so it throws rather than risk killing an innocent process.

Source

Thrown at config/scripts/macos-computer-helper-owner-loss-processes.mjs:348

const processSignalOperations = {
  processIdentity,
  signalProcess: process.kill.bind(process)
}

export function signalProcessIdentity(
  identity,
  expectedCommandFragment,
  signal,
  operations = processSignalOperations
) {
  validateDetachedIdentity(identity, expectedCommandFragment)
  const currentIdentity = operations.processIdentity(identity.pid)
  if (!currentIdentity) {
    return false
  }
  if (!sameIdentity(currentIdentity, identity)) {
    throw new Error('Recorded benchmark helper PID now belongs to another process')
  }
  let stopped = false
  try {
    operations.signalProcess(identity.pid, 'SIGSTOP')
    stopped = true
    const stoppedIdentity = operations.processIdentity(identity.pid)
    if (!sameIdentity(stoppedIdentity, identity)) {
      throw new Error('Recorded benchmark helper PID changed before signaling')
    }
    operations.signalProcess(-identity.pgid, signal)
    if (signal !== 'SIGKILL') {
      operations.signalProcess(-identity.pgid, 'SIGCONT')
    }
    stopped = false
    return true
  } catch (error) {
    let resumeError
    if (stopped) {

View on GitHub (pinned to 1136503c6a)

Solutions

1. Re-spawn the helper and re-record its identity rather than signaling the recycled pid
2. Reduce latency between writeProcessRecord and signalProcessIdentity so recycling is unlikely
3. Use killRecordedProcess which combines identity check + exit wait, and pair it with killProcessMatchingCommand as a fallback
4. Confirm the recorded command fragment is unique enough that a recycled pid is unlikely to match by coincidence

import { processIdentityIsCurrent } from './macos-computer-helper-owner-loss-processes.mjs'

if (!processIdentityIsCurrent(recorded)) {
  // pid was recycled; do NOT signal
  return
}

try {
  signalProcessIdentity(recorded, frag, 'SIGKILL')
} catch (error) {
  if (/now belongs to another process/.test(error.message)) {
    killProcessMatchingCommand([frag])
  } else throw error
}

When it happens

Trigger: operations.processIdentity(identity.pid) returns a non-null identity whose pid matches but pgid or command differs from the recorded identity.

Common situations: Long gaps between recording the helper PID (writeProcessRecord) and acting on it; systems with aggressive PID wrapping (containers, macOS under load); or a recorded identity that was never detached (validateDetachedIdentity requires pgid === pid) so the OS reuses the pid freely after the helper exits.

Related errors

• Benchmark process group anchor changed before signaling
• Recorded benchmark helper PID changed before signaling
• Benchmark pending anchor recovery failed
• Benchmark process group changed before signaling
• Benchmark process group signal recovery failed

AI-assisted analysis of stablyai/orca@1136503c6a (2026-08-12). Data as JSON: /api/errors/a23028258978e699. Report an issue: GitHub.