huggingface/open-r1 · error · PistonError

language={response['language']}, version={response['version'

Error message

language={response['language']}, version={response['version']}, exit code={response['run']['code']}, stderr={response['run']['stderr']}, signal={response['run']['signal']}

What it means

When the submission's run finishes with a non-zero exit code that isn't a recognized timeout (SIGKILL) or memory-error pattern, execute_ioi raises PistonError embedding language, version, exit code, stderr, and signal. This means the program crashed or exited with an error status outside the handled special cases.

Source

Thrown at src/open_r1/utils/competitive_programming/ioi_scoring.py:332

            "stderr"
        ]

    if "run" not in response:
        raise PistonError(response)

    if response["run"]["code"] == 1 and "MemoryError" in response["run"]["stderr"]:
        return "0", "Memory limit exceeded"

    # successful result
    if response["run"]["stdout"]:
        return response["run"]["stdout"], response["run"]["stderr"]

    if response["run"]["signal"] == "SIGKILL":
        return "0", "Time limit exceeded"

    # other issues
    if response["run"]["code"] != 0:
        raise PistonError(
            f"language={response['language']}, version={response['version']}, exit code={response['run']['code']}, stderr={response['run']['stderr']}, signal={response['run']['signal']}"
        )
    return "0", "Unknown error"

View on GitHub (pinned to 1416fa0cf2)

Solutions

  1. Read stderr and the exit code in the message — they identify the actual runtime failure (missing .so, Python traceback, segfault signal, etc.).
  2. Fix the submitted solution so it exits 0; IOI scoring expects the program to run to completion on each test case.
  3. Verify the worker image includes all libraries/toolchain the solution needs (matching the IOI package spec).
  4. If crash is input-dependent, reproduce locally with the failing test and add robustness (e.g. bounds checks, correct I/O parsing).

Example fix

// before: solution crashing on empty input
lines = open('input.txt').readlines(); n, m = map(int, lines[0].split())
// after: guard against malformed input
lines = open('input.txt').read().split(); n, m = (int(lines[0]), int(lines[1])) if len(lines) >= 2 else (0, 0)
Defensive patterns

Strategy: try-catch

Validate before calling

# no reliable pre-call check; validate the solution compiles and exits 0 on sample tests locally before submission
subprocess.run(['./compile'], cwd='workspace', check=True)

Type guard

def crashed_unexpectedly(run: dict) -> bool:
    return run.get('code', 0) != 0 and run.get('signal') != 'SIGKILL' and 'MemoryError' not in (run.get('stderr') or '')

Try / catch

try:
    score, feedback = await execute_ioi(client, data)
except PistonError as e:
    m = re.search(r'exit code=(\d+), stderr=(.*), signal=(\S+)', str(e))
    logger.error('Submission crashed: exit=%s signal=%s stderr=%s', *(m.groups() if m else ('?', '?', e)))
    score, feedback = '0', 'Runtime error'

Prevention

When it happens

Trigger: response['run']['code'] != 0 while signal != 'SIGKILL' and stderr does not contain 'MemoryError' — e.g. the compiled program aborted, threw an unhandled exception at startup, or a checker/grader wrapper failed.

Common situations: Solution crashes on reading malformed input format; missing runtime libraries on the Piston worker so the binary fails to start; exit code conventions of a custom wrapper differing from expected; stack overflow / assertion aborts not caught by the MLE/TLE heuristics.

Related errors


AI-assisted analysis of huggingface/open-r1@1416fa0cf2 (2026-08-30). Data as JSON: /api/errors/45e5ea6ea58bda5e. Report an issue: GitHub.