Stream: git-wasmtime

Topic: wasmtime / issue #12497 PCC regression notification

Wasmtime GitHub notifications bot (Feb 02 2026 at 20:29):

joell opened issue #12497:

Hi. This is a tragically unhelpful bug report -- in that I do not have a WASM file I am able to share to reproduce it -- but I have narrowed down the exact version of wasmtime in which the regression occurred. I am sharing what I know and can communicate purely in hopes that someone finds it useful in connection with some other issue, without any expectation anyone can act on this limited information.

Test Case

(unable to provide)

Steps to Reproduce

Load a .wasm file as a Component::from_binary with cranelift_pcc(true) in the Engine's Config.

Expected Results

The component loads.

Actual Results

Under wasmtime 37.0.2 the Component loads without any issue.
Under wasmtime 38.0.1 the Component load fails with this error:

Failure loading WASM extracted algorithms.: Compilation error: Proof-carrying-code validation error: UnimplementedInst

Versions and Environment

Wasmtime version or commit: 38.0.1

Operating system: Arch Linux

Architecture: x86-64

Extra Info

Once again, I'm sorry I cannot provide a .wasm file to reproduce this. I just wanted to do the courtesy of reporting what I knew, without any expectation of response to it. My only hope is that this information might be valuable the next time someone looks at the PCC system. Feel free to close and discard this issue at your pleasure.

Wasmtime GitHub notifications bot (Feb 02 2026 at 20:29):

joell added the bug label to Issue #12497.

Wasmtime GitHub notifications bot (Feb 02 2026 at 20:59):

cfallin commented on issue #12497:

Hi @joell -- thanks for the bug report.

It's known that PCC is not currently being tested in CI, so it's likely and in fact even probable that we'll have more cases like this over time, up until the point that we're able to bring it up to date and get it in CI so it stays that way.

This report simply states that there exists some Wasm file for which PCC is incomplete. Since no Wasm file is actually provided, I'll go ahead and close it, as the underlying state is already known. Please do feel free to file another issue (and/or PR to fix!) if you have a concrete example. Thanks!

Wasmtime GitHub notifications bot (Feb 02 2026 at 20:59):

cfallin closed issue #12497:

Hi. This is a tragically unhelpful bug report -- in that I do not have a WASM file I am able to share to reproduce it -- but I have narrowed down the exact version of wasmtime in which the regression occurred. I am sharing what I know and can communicate purely in hopes that someone finds it useful in connection with some other issue, without any expectation anyone can act on this limited information.

Test Case

(unable to provide)

Steps to Reproduce

Load a .wasm file as a Component::from_binary with cranelift_pcc(true) in the Engine's Config.

Expected Results

The component loads.

Actual Results

Under wasmtime 37.0.2 the Component loads without any issue.
Under wasmtime 38.0.1 the Component load fails with this error:

Failure loading WASM extracted algorithms.: Compilation error: Proof-carrying-code validation error: UnimplementedInst

Versions and Environment

Wasmtime version or commit: 38.0.1

Operating system: Arch Linux

Architecture: x86-64

Extra Info

Once again, I'm sorry I cannot provide a .wasm file to reproduce this. I just wanted to do the courtesy of reporting what I knew, without any expectation of response to it. My only hope is that this information might be valuable the next time someone looks at the PCC system. Feel free to close and discard this issue at your pleasure.

Wasmtime GitHub notifications bot (Mar 17 2026 at 23:22):

kayabaNerve commented on issue #12497:

I noted this here: https://github.com/bytecodealliance/wasmtime/issues/11850#issuecomment-3507558121

My work is public, but not minimal. I can confirm that:

git clone https://github.com/serai-dex/serai
cd serai
git checkout 1faaf0e9d8c319d3d4dcc7fdde64af3210eafcec
docker build -f ./orchestration/runtime/Containerfile .

will create an image which has busybox available (providing basic utilities) and a relevant WASM file at /serai.wasm. For a non-Docker solution, one can run cargo build -p serai-runtime --no-default-features for a serai_runtime.wasm _somewhere_ within the target directory, though I assume as this isn't a minimal solution, the safety of the containerized method will be preferred. I can confirm this for the release (Docker) and debug (non-Docker) builds. All I did was build an engine, enable PCC, and then invoke precompile_module on the contents of the .wasm file to encounter UnimplementedInst.

Regarding the WASM, it does target wasm32v1-none which hopefully removes a lot of potential headaches. I believe the lack of documentation, and lacking of testing, show how PCC should be removed if there isn't sufficient maintenance for it (as curl removes such backends), or moved behind an experimental feature as it isn't generally fit and isn't tested in the CI, or this does need to be allocated some care so it is generally usable and can be expected to remain that way. To quote its doc string, and to justify why I say this,

This guards against bugs in instruction lowering that might create holes in the Wasm sandbox.

PCC is designed to be fast: it does not require complex solvers or logic engines to verify, but only a linear pass over a trail of “breadcrumbs” or facts at each intermediate value. Thus, _it is appropriate to enable in production_.

(emphasis added)

Wasmtime GitHub notifications bot (Mar 17 2026 at 23:24):

kayabaNerve edited a comment on issue #12497:

I noted this here: https://github.com/bytecodealliance/wasmtime/issues/11850#issuecomment-3507558121

My work is public, but not minimal. I can confirm that:

git clone https://github.com/serai-dex/serai
cd serai
git checkout 1faaf0e9d8c319d3d4dcc7fdde64af3210eafcec
docker build -f ./orchestration/runtime/Containerfile .

will create an image which has busybox available (providing basic utilities) and a relevant WASM file at /serai.wasm. For a non-Docker solution, one can run cargo build -p serai-runtime --no-default-features for a serai_runtime.wasm _somewhere_ within the target directory, though I assume as this isn't a minimal solution, the safety of the containerized method will be preferred. I can confirm this for the release (Docker) and debug (such as the non-Docker command I provided) builds. All I did was build an engine, enable PCC, and then invoke precompile_module on the contents of the .wasm file to encounter UnimplementedInst.

Regarding the WASM, it does target wasm32v1-none which hopefully removes a lot of potential headaches. I believe the lack of documentation, and lacking of testing, show how PCC should be removed if there isn't sufficient maintenance for it (as curl removes such backends), or moved behind an experimental feature as it isn't generally fit and isn't tested in the CI, or this does need to be allocated some care so it is generally usable and can be expected to remain that way. To quote its doc string, and to justify why I say this,

This guards against bugs in instruction lowering that might create holes in the Wasm sandbox.

PCC is designed to be fast: it does not require complex solvers or logic engines to verify, but only a linear pass over a trail of “breadcrumbs” or facts at each intermediate value. Thus, _it is appropriate to enable in production_.

(emphasis added)

Wasmtime GitHub notifications bot (Mar 18 2026 at 13:08):

cfallin commented on issue #12497:

Yeah, that doc-comment is definitely aspirational. In some sense the PCC work was an experiment in very fine-grained in-tree development of a research idea (as opposed to separate-branch-then-integrate), and I think it could have worked if priorities hadn't shifted, but unfortunately it's pretty bitrotted right now. (To give some background, I developed this in a sliver of free time I had, then went on parental leave for 3 months just before getting to the point of enabling it in CI, and when I came back priorities were different.)

It has remained in tree with the aspiration that we'll get back to it at some point, but at the very least we should update docs; and probably it's actually better to delete it then if/when eventually re-enlivened, start with reapplying the diff. We aren't getting too much value out of the bits in tree staying "up to date" typechecking-wise for example.

I'll send a PR to do that.

Wasmtime GitHub notifications bot (Mar 18 2026 at 14:49):

kayabaNerve commented on issue #12497:

I definitely appreciate the idea!

But I also understand our time and energy isn't infinite, and respect it hasn't been something that's managed to survive in a healthy state. Wishing you the best personally!

Last updated: Mar 23 2026 at 16:19 UTC