3i: panic caused by multiple grate context registrations in single grate

[Yaxuan-w]

Thanks to @stupendoussuperpowers for spotting this bug.

We discovered a panic [3i|_add_global_grate] attempt to overwrite existing grate entry for grateid that occurs when calling register_handler multiple times inside the same grate to register different handlers. The root cause is that we were registering the grate context multiple times, rather than only updating the handler table.

During the previous refactor of the grate execution flow, I changed the context-registration logic so that the grate context would be sent to 3i every time register_handler is invoked. This inadvertently caused repeated context registrations for the same grate.

My current fix is to add a cageid–based check inside 3i so that a grate context is only registered once per cage.

Since this issue only manifests when the entire lind-wasm is running, it cannot be fully captured by existing 3i unit tests, even though we have tests inside 3i that appear to cover this scenario. As part of the fix PR, we will also need to add a dedicated test case in the unit-test folder to ensure this behavior is properly validated going forward.

[Yaxuan-w]

Per discussion with Justin and Sanchit, we'll refactor the storing location of vmctx pointer. After refactoring, Wasmtime hold the wasm instances’ pool (—> not store in the 3i)

When initializing, wasmtime will create 10 copies and store them in either linked list or array attached by cageid.

In trampoline function, the execution flow will look like:

Mycontext = getfreecontext(grated) // pop
do_call(grateid, fn_ptr, my_context)
free_context(grated, mycontext) // push

This should help resolve the above register_handler issue.

[JustinCappos]

10 was an example, but may be fine. It may be high. I don't know. Definitely be sure to do a debugging_panic if you reach the limit and all are full. You could decide to do this upon the first regsiter_call_handler instead if you want to avoid this cost for other cages.

…

On Mon, Nov 24, 2025 at 1:58 PM Alice Wen ***@***.***> wrote: *Yaxuan-w* left a comment (Lind-Project/lind-wasm#538) <#538 (comment)> Per discussion with Justin and Sanchit, we'll refactor the storing location of vmctx pointer. After refactoring, Wasmtime hold the wasm instances’ pool (—> not store in the 3i) When initializing, wasmtime will create 10 copies and store them in either linked list or array attached by cageid. In trampoline function, the execution flow will look like: Mycontext = getfreecontext(grated) // pop do_call(grateid, fn_ptr, my_context) free_context(grated, mycontext) // push This should help resolve the above register_handler issue. — Reply to this email directly, view it on GitHub <#538 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRODZIDTAUQSRMKWJVVAT36NIO7AVCNFSM6AAAAACNBKHA4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNZSGI3DKNBSHA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>