Found in the post-#933 survey and re-executed today on a Debug build of main (538a667a), with node v24.4.1 as the oracle. Each program builds a chain of no-trap proxies, p = new Proxy(p, {}) repeated N times over function(){ return 42; }, then applies one operation to the outermost proxy. #934 was closed with proxy chains reported as no longer overflowing, but these paths still crash:
| operation | N | node | zig-js |
|---|---|---|---|
p() | 4,000 | 42 | Segmentation fault |
new p() | 4,000 | RangeError | Segmentation fault |
Object.getOwnPropertyDescriptor(p, "length") | 4,000 / 100,000 | RangeError | Segmentation fault |
p() | 100,000 | 42 | TypeError: p is not a function |
| building the chain | 100,000 | fast | ~35 s |
Causes:
callValueWithThisAtSiteforwards a no-trap proxy call by recursing on the target, one native frame per link, with no stack guard on that path.[[Construct]]and[[GetOwnProperty]]have the same shape.Object.isCallableObjectwalks the proxy→target chain to find out whether a proxy is callable, and returnsfalseafter 10,000 hops. The Proxy constructor calls it for every new proxy, so a chain of N costs O(N²) to build. It also stores a wrongproxy_callablefor every link past 10,000, so the call fails with a TypeError. Yet ProxyCreate fixes a proxy's [[Call]] at creation from IsCallable(target) (10.5.14), and zig-js already records exactly that inbehavior.proxy_callable, so answering from the proxy's own flag is O(1) and exact.
Fix: answer callability from the flag, forward no-trap [[Call]]/[[Construct]] links in a loop (each step performs the same revocation check and trap lookup, in the same order as the recursion), and give the descriptor path the nesting guard the other traps use (#940), so a deep chain throws RangeError instead of crashing.
Done: no segfault on any operation at 4,000 or 100,000 links. Calls return 42 at both depths, typeof is function at any depth, and building 100,000 links is linear. Pinned as focused cases. Debug before/after --diag over test/built-ins/Proxy, Reflect, Function and Object, plus the call/new/typeof expression subtrees, shows 0 failures on both sides.