bug: wasmtime stack corruption

[drapl0n]

Executing strace-grate causes stack pointer to override frame pointer causing an overflow:

lind-wasm/src/wasmtime/crates/wasmtime/src/runtime/vm/traphandlers/backtrace.rs

Lines 182 to 190 in 0de0b4e

	// At the start of each iteration of the loop, we know that `fp` is
	// a frame pointer from Wasm code. Therefore, we know it is not
	// being used as an extra general-purpose register, and it is safe
	// dereference to get the PC and the next older frame pointer.
	// The stack grows down, and therefore any frame pointer we are
	// dealing with should be less than the stack pointer on entry
	// to Wasm.
	assert!(trampoline_sp >= fp, "{trampoline_sp:#x} >= {fp:#x}");

During the initial triage issue appeared to be due to the large number of registered syscall handlers. Reducing the number of registered syscalls prevented the panic, which initially suggested stack size exhaustion issue.

Further debugging resulted that the root cause of the panics are syscalls that requires multi-threading: exec , exit, fork and clone. They can be interposed but forwarding them causes an unexpected behavior.

Building lind with the latest PR (that enables wasmtime backtrace) throws completely different errors and panics at:

thread 'lind-fork-2' (505124) panicked at /home/lind/lind-wasm/src/wasmtime/crates/fdtables/src/dashmaparrayglobal.rs:86:5:
Unknown cageid in fdtable access

thread 'lind-fork-2' (505124) panicked at /rustc/8387095803f21a256a9a772ac1f9b41ed4d5aa0a/library/core/src/panicking.rs:225:5:
panic in a function that cannot unwind

The syscall invoked immediately before the panic is exit and associated cageid is 777777 which corresponds to RawPOSIX.

Additionally, the output produced by the grate is non-deterministic and might be due #774.

This issue can be reproduced by executing strace-grate with any test in our test suite.

@Yaxuan-w

[Yaxuan-w]

Awesome catches!

During the initial triage issue appeared to be due to the large number of registered syscall handlers. Reducing the number of registered syscalls prevented the panic, which initially suggested stack size exhaustion issue.

I remembered that we can increase stack size at either compilation time or initialization. This probably can explain the Stack corruption / invalid backtrace error I met previous: #538 (comment).

Further debugging resulted that the root cause of the panics are syscalls that requires multi-threading: exec , exit, fork and clone. They can be interposed but forwarding them causes an unexpected behavior.
The syscall invoked immediately before the panic is exit and associated cageid is 777777 which corresponds to RawPOSIX.
Additionally, the output produced by the grate is non-deterministic

Could you run again once #798 being merged to see if those errors still exist?

Building lind with the latest PR (that enables wasmtime backtrace) throws completely different errors and panics at:

I'm quite confused about this error... Would love to hear people's thoughts..

[drapl0n]

stack size can be increased in the config unless it is overridden somewhere else:

lind-wasm/src/wasmtime/crates/wasmtime/src/config.rs

Lines 228 to 236 in 836cedc

	// 512k of stack -- note that this is chosen currently to not be too
	// big, not be too small, and be a good default for most platforms.
	// One platform of particular note is Windows where the stack size
	// of the main thread seems to, by default, be smaller than that of
	// Linux and macOS. This 512k value at least lets our current test
	// suite pass on the main thread of Windows (using `--test-threads
	// 1` forces this), or at least it passed when this change was
	// committed.
	max_wasm_stack: 512 * 1024,

after inspecting previous panics and errors, i highly suspect it to be the same stack corruption bug.

building lind-wasm with changes made in #798 triggers the condition where target_id != RawPOSIX_cage_id and panics:

thread 'lind-fork-2' (661219) panicked at /home/lind/lind-wasm/src/wasmtime/crates/threei/src/handler_table/hashmap_impl.rs:119:17:
Handler not found for (self_cageid=1, syscall_num=9, target_cageid=2)

[stupendoussuperpowers]

building lind-wasm with changes made in #798 triggers the condition where target_id != RawPOSIX_cage_id and panics:

This should be a separate issue since it's not related to the stack sizes. Or perhaps you could add this as a review to that PR too. That should be a simpler fix I guess.

Building lind with the latest PR (that enables wasmtime backtrace) throws completely different errors and panics at:

Does --wasmtime-backtrace not give more info about this error? Regardless I think that flag is only helpful for wasm traps and this seems to be a host panic. It's possible that it's just reporting the generic code in stdlib that is called to panic.

[Yaxuan-w]

Does --wasmtime-backtrace not give more info about this error? Regardless I think that flag is only helpful for wasm traps and this seems to be a host panic. It's possible that it's just reporting the generic code in stdlib that is called to panic.

Yeah I think wasmtime backtrace only printing wasm stack info when panic happens. If we want a more detailed error msg in host, probably we'll need rust backtrace.

[drapl0n]

This should be a separate issue since it's not related to the stack sizes. Or perhaps you could add this as a review to that PR too. That should be a simpler fix I guess.

It has been fixed after changing target_id to RawPOSIX's cage_id in the grate.

[JustinCappos]

@Yaxuan Wen ***@***.***> How does this relate to what we discussed?

…

On Sun, Feb 22, 2026 at 1:45 PM drapl0n ***@***.***> wrote: *drapl0n* left a comment (Lind-Project/lind-wasm#797) <#797 (comment)> This should be a separate issue since it's not related to the stack sizes. Or perhaps you could add this as a review to that PR too. That should be a simpler fix I guess. It has been fixed after changing target_id to RawPOSIX's cage_id in the grate. — Reply to this email directly, view it on GitHub <#797 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD42HDKYHYMRZ4JMNYD4NH2LPAVCNFSM6AAAAACV3P55YCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNBRGUYTENRRGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Yaxuan-w]

How does this relate to what we discussed?

The bug is caused by incorrectly using target_cageid in strace grate. It set the target_cageid to be the child cage's cageid in a grate call (this should be grate's cageid in our discussion OR the rawposix cageid in my last night's version), so it'll always panic. In other words, this is not related to our discussion but related to how grate using make_3i_call.

I just pushed a new updates which reverts the glibc modifications back. This will influence the strace grate to use grate's cageid as its target cageid when forwarding a syscall for a cage from it.