[tannevaled]

vm: p on a self-referential object or Struct killed the process

Three lines of ordinary Ruby, measured on main (3a3fb81):

$ rbgo -e 'class Node; attr_accessor :peer; end
           a = Node.new; b = Node.new; a.peer = b; b.peer = a
           p a'
runtime: goroutine stack exceeds 1000000000-byte limit
fatal error: stack overflow
$ echo $?
2

Two ordinary objects pointing at each other. A doubly-linked list, a parent
with a back-pointer, an ORM association. And a fatal error: stack overflow is
not a panic: callNative's recover cannot convert it, and nothing else can
either — the embedding host dies with the interpreter, which is precisely what
that recover exists to prevent ("arbitrary input from an embedding host — the
wasm playground REPL, say — can never crash the process", object_model.go:1552).

No adversary is required. This is a bug an ordinary program walks into.

The population the existing guard had cleared

internal/object's ReprEnter/ReprLeave is the right mechanism and was
already used by Array, Hash, Set, Data and Enumerator —
TestRecursiveStructureInspect covers exactly those. defaultObjectInspect
(builtins.go) and Struct#to_s/#inspect (struct.go) never reached it.

Measured, every case exit 2 on main and exit 0 here:

	main	this branch
a.peer = b; b.peer = a; p a	fatal, exit 2	#<Node:0x…08 @peer=#<Node:0x…10 @peer=#<Node:0x…08 ...>>>
class K; def initialize; @me = self; end; end; K.new.inspect	fatal	#<K:0x…08 @me=#<K:0x…08 ...>>
a.peer = a; p [a]	fatal	[#<N2:0x…08 @peer=#<N2:0x…08 ...>>]
a.peer = a; p({k: a})	fatal	{k: #<N3:0x…08 @peer=#<N3:0x…08 ...>>}
S = Struct.new(:x); s = S.new(nil); s.x = s; s.inspect	fatal	#<struct S x=#<struct S:...>>
…; s.to_s	fatal	same
…; s.to_a.inspect	fatal	[#<struct S x=#<struct S:...>>]

⛔ Wrapping it in an Array or a Hash did not save it, and that is the part
worth noticing: those guard THEIR OWN identity, so the container printed once
and the recursion came straight back through the object's inspect. A guard over
five types is not a guard over the five types' members.

The renderings are MRI's, from the two functions that do this upstream

Both use rb_exec_recursive, and both were read at tag v4.0.9:

• object.c, inspect_obj: if (recur) rb_str_cat2(str, " ..."); then ">".
  So a re-entered object prints #<Node:0x0000000000000008 ...>.
• struct.c, inspect_struct: if (recur) return rb_str_cat2(str, ":...>");.
  So a re-entered named struct prints #<struct S:...>.

⚠ One deliberate divergence, recorded at the site rather than guessed at: MRI
appends the class path on re-entry even for an anonymous struct, where it
omits it otherwise (if (recur || first != '#')), so MRI would print
#<struct #<Class:0x…>:...>. This keeps rbgo's own naming rule in both cases
and prints #<struct:...>. The value of the change is not dying; that corner
can be matched separately if anyone wants it.

Tests

TestRecursiveObjectAndStructInspectDoNotKillTheProcess in
crash_hardening_test.go — beside the test whose population was too narrow,
deliberately, so the two read together.

Its last two cases are the negative control, and they matter as much as the
rest: the guard must CLEAR between siblings, or p [x, x] would print the second
x as ... and silently corrupt ordinary output. Both an object and a struct
are checked that way.

-race clean on these paths (ReprEnter is mutex-guarded and the lock is never
held across the recursion, as its own comment states). Full internal/vm suite
green, 246s, -count=1. gofmt and go vet clean.

Where it came from

Auditing #768 — "no call-depth limit … kills the embedding host with a fatal Go
stack overflow" — which is fixed but still open: def f; f; end; f now
raises a rescuable SystemStackError and the program survives. I probed 16 other
recursion shapes (lambda, proc, send, public_send, method_missing, mutual, block
through each/map, define_method, instance_eval, to_proc, Comparable) and the
depth guard covers every one of them.

What it does not cover is recursion that is not Ruby-level calls: the repr
walk is Go recursion through Inspect(), so no call-depth counter sees it. That
is this change.

#768 should be closed on the strength of that probe; I have left it open and
said so there rather than closing someone else's issue from a side quest.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

🤖 Generated with Claude Code

[tannevaled]

The neighbours were checked, and they are fine

A fix to one Go-recursion path invites the question of the others, so I probed
every path I could think of that walks a user-controlled object graph in Go.
Each in its own process, on this branch's binary, so one crash could not hide
the rest. All exit 0:

	answer
a = []; a << a; b = []; b << b; a == b	true
h[:k] = h; g[:k] = g; h == g	true
S = Struct.new(:x); a.x = a; b.x = b; a == b	true
a = []; a << a; a.hash	an Integer
S.new(nil) self-referential, .hash	an Integer
a = []; a << a; a.flatten	ArgumentError: tried to flatten recursive array — MRI's exact message
a = []; a << a; Marshal.dump(a)	6 bytes (an object link)
require "json"; a << a; JSON.generate(a)	JSON::NestingError: nesting of 100 is too deep…

So equality, hashing, flatten and both serialisers already guard themselves —
MRI uses rb_exec_recursive_paired for the first three (struct.c:1444, 1525) and
rbgo matches. The inspect/to_s path was the only gap in this class that I
could find, which is also why it is the only thing this PR changes.

Depth without a cycle is a different vector, and it holds too

An identity guard does nothing for a structure that is merely very deep — there
is no repeat to detect. Worth probing because it is reachable from parsing:

$ rbgo -e 'a = []; 200000.times { a = [a] }; puts a.inspect.length'
400002
$ rbgo -e 'a = []; 200000.times { a = [a] }; p Marshal.dump(a).bytesize'
400004

200,000 levels, both fine — a Go goroutine stack grows on demand toward the 1 GB
limit, so a shallow frame repeated that often still fits. And the usual way such
a structure would arrive from outside is capped before it gets here: JSON refuses
at nesting 100.

I am not claiming a bound was proven. I am saying the depth vector was looked
for, that 200k is well past anything a parser will hand us, and that the failure
this PR fixes needed no depth at all — two objects were enough.

🤖 Generated with Claude Code