fitzgen opened PR #12933 from fitzgen:add-gc-zeal-integrity-checks to bytecodealliance:main:
- Poison freed GC objects and new heap memory
- Assert newly-allocated objects are filled with poison pattern
- Add
gc_assert!checks for validVMGcKindonGcHeap::index[_mut]- Add
gc_assert!checks for validVMGcKindduring tracing- Add
VMGcKind::try_from_u32()for fallible kind validation- Add over-approximated stack roots list integrity checks, called before and after trace and sweep. Validates kind, in-list bit, ref count, and that the list is not cyclic.
- Add assertion that all free blocks of memory contain the poison pattern, before and after trace and sweep
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
fitzgen requested wasmtime-core-reviewers for a review on PR #12933.
fitzgen requested alexcrichton for a review on PR #12933.
fitzgen requested wasmtime-compiler-reviewers for a review on PR #12933.
github-actions[bot] added the label wasmtime:api on PR #12933.
github-actions[bot] added the label wasmtime:ref-types on PR #12933.
github-actions[bot] commented on PR #12933:
Subscribe to Label Action
cc @fitzgen
<details>
This issue or pull request has been labeled: "wasmtime:api", "wasmtime:ref-types"Thus the following users have been cc'd because of the following labels:
- fitzgen: wasmtime:ref-types
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
alexcrichton submitted PR review.
alexcrichton created PR review comment:
Also, I'd recommend unconditional calls below and a conditional early-return in the function itself here.
alexcrichton created PR review comment:
if cfg!(gc_zeal)instead of#[cfg]
alexcrichton created PR review comment:
I'm a bit confused by how this works. If the counter is positive,
alloc_rawis runn, wouldn't this execute here too? I figured that theNonecase up above would resetgc_zeal_alloc_counterand otherwise this block wouldn't be needed here.
alexcrichton created PR review comment:
And one final thought: with a
#[cfg]this means that it's not factored into the caching logic for example and isn't visible inTunables(e.g. compile with-zeal and then load into without-zeal or vice-versa). Not a huge concern necessarily but figured I'd write down anyway
alexcrichton created PR review comment:
This is probably me just not being used to "zeal", but to me the naming here is pretty disconnected from the purpose. IIUC this env var is "return OOM everything nth allocation" which to me would be better named something like
WASMTIME_GC_ZEAL_OOM_AFTERor something like that. Maybe I just don't like the name "zeal" since I have no idea what it's connected to...
fitzgen submitted PR review.
fitzgen created PR review comment:
Yeah, I'd like to also add it to tunables eventually, so we can use it during fuzzing. Will cross that bridge when we get to it though.
fitzgen submitted PR review.
fitzgen created PR review comment:
Yeah, I futzed around with this and made it more complicated than needed. Will simplify.
fitzgen submitted PR review.
fitzgen created PR review comment:
The OOM is just a mechanism, what its real purpose is to force GC after every
Nallocations.
fitzgen updated PR #12933.
fitzgen has enabled auto merge for PR #12933.
fitzgen added PR #12933 Add GC zeal assertions to the merge queue.
fitzgen merged PR #12933.
fitzgen removed PR #12933 Add GC zeal assertions from the merge queue.
Last updated: Apr 13 2026 at 00:25 UTC