GeezerVison

Summary

json.loads() on a deeply-nested array or object overflows the native Rust stack and crashes the interpreter process with SIGSEGV. CPython raises RecursionError on the same input.

import json
json.loads('[' * 50000 + ']' * 50000)
# RustPython (before): SIGSEGV (exit 139)
# CPython:             RecursionError: maximum recursion depth exceeded
# RustPython (after):  RecursionError: maximum recursion depth exceeded while
#                         decoding a JSON object from a string

Root cause

The scanner has a mutual-recursion chain in crates/stdlib/src/json.rs:

JsonScanner::parse_object / parse_array
  -> JsonScanner::call_scan_once
    -> JsonScanner::parse_object / parse_array  (recurse)

call_scan_once is the single choke point every descent passes through, but
it wasn't wrapped in a recursion guard. Each nesting level consumes a pair
of Rust stack frames (parse_X + call_scan_once), so input depth ~45k
exhausts the 8 MB main thread stack on macOS and the OS kills the process
with SIGSEGV.

CPython's Modules/_json.c handles this with _Py_EnterRecursiveCall(\" while decoding a JSON object from a string\"), which translates native recursion into RecursionError at sys.getrecursionlimit().

Fix

Wrap the body of call_scan_once with vm.with_recursion(\"while decoding a JSON object from a string\", || { ... }). Same machinery RustPython already uses for comparison, __repr__, __subclasscheck__, and AST traversal (see protocol/object.rs and stdlib/_ast/node.rs).

The guard is placed at call_scan_once rather than on parse_object / parse_array individually because every recursive descent funnels through call_scan_once — one wrap covers array, object, and alternating nesting with a single point of maintenance.

Verification

$ cargo +1.94.0 build --release
   Finished \`release\` profile [optimized] target(s) in 41s

$ ./target/release/rustpython -c \"import json; json.loads('[' * 50000 + ']' * 50000)\"
Traceback (most recent call last):
  File \"<stdin>\", line 1, in <module>
RecursionError: maximum recursion depth exceeded while decoding a JSON object from a string

$ ./target/release/rustpython extra_tests/snippets/stdlib_json.py
(passes silently — includes 3 new regression cases)

$ ./target/release/rustpython -m test test_json
Ran 214 tests in 6.700s
OK (skipped=9, expected failures=13)
Result: SUCCESS

Tested surfaces

CPython parity note

After the fix, RustPython raises RecursionError at JSON depth >= ~1000 (VM default recursion_limit). CPython raises it at depth >= ~10000 due to a different stack-headroom heuristic in _Py_EnterRecursiveCall. Both refuse to crash; exact threshold is tunable via sys.setrecursionlimit(). Real-world JSON is rarely deeper than 50 levels, so the difference is not user-visible in practice.

Scope

• In: recursion guard on call_scan_once — covers all three nesting patterns above
• Out: encoder side (iterative, already safe), string/number parsing (non-recursive), scan_once Python-callback fallback path (already counted by VM frame machinery)

Related

• Prior security fix using the same vm.with_recursion pattern: Fix segfault on cyclic or deeply-nested AST in compile() #7630 (cyclic AST in compile())
• CPython reference: Modules/_json.c scanner_call / _scan_once uses _Py_EnterRecursiveCall

Summary by CodeRabbit

• Bug Fixes

  • JSON parser now raises RecursionError when decoding extremely deeply nested JSON structures (arrays, objects exceeding ~100,000 nesting levels) instead of causing potential stack overflow crashes.

• Tests

  • Added regression tests for JSON parsing with extremely deeply nested arrays, objects, and alternating nesting patterns.