SingleAccretion opened issue #9899:
I am sure everyone building wasmtime is familiar with:
warning: cranelift-codegen@0.116.0: Failed to run `rustfmt` on ISLE-generated code: Custom { kind: Other, error: "`rustfmt` exited with status exit code: 0xc00000fd" }
It is a constant feature of the CI builds as well.
0xc00000fd
isSTATUS_STACK_OVERFLOW
.
SingleAccretion edited issue #9899:
I am sure everyone building wasmtime is familiar with:
warning: cranelift-codegen@0.116.0: Failed to run `rustfmt` on ISLE-generated code: Custom { kind: Other, error: "`rustfmt` exited with status exit code: 0xc00000fd" }
It is a constant feature of the CI builds as well.
0xc00000fd
isSTATUS_STACK_OVERFLOW
.
cfallin commented on issue #9899:
Fascinating -- I wonder if this is a
rustfmt
failure to handle very large functions without recursing. We've run into similar issues with ISLE-generated code being too large for tools in rust-lang/rust#128422; the ultimate fix should be to the tool IMHO, but...In the meantime perhaps we can stop running rustfmt on the code here? I don't recall the exact reason we decided to do that; it dates back to the original ISLE integration in this commit. Perhaps we were worried about human readability of the generated code. In any case, we rarely (or at least I rarely?) look at this generated code today, so if it's causing any problems in CI we can skip it. Happy to review a PR for that (with some delay, this is a holiday week for most of us).
cfallin closed issue #9899:
I am sure everyone building wasmtime is familiar with:
warning: cranelift-codegen@0.116.0: Failed to run `rustfmt` on ISLE-generated code: Custom { kind: Other, error: "`rustfmt` exited with status exit code: 0xc00000fd" }
It is a constant feature of the CI builds as well.
0xc00000fd
isSTATUS_STACK_OVERFLOW
.
alexcrichton commented on issue #9899:
I've seen a similar error in CI quite a lot but I always figured it was because
rustfmt
wasn't installed and that error wasn't otherwise specifically handled. Otherwise though:I am sure everyone building wasmtime is familiar with:
I never actually saw this day-to-day myself and I think it's a Windows-specific issue where Windows has smaller thread stacks by default than other platforms (or at least I think, maybe I'm wrong...).
Mostly just wanted to highlight that you might be one of the first developers to frequently work on Wasmtime on Windows, so please keep your eyes peeled for any other gotchas and points of friction. Most of the preexisting maintainers I believe don't develop day-to-day on Windows, so I wouldn't be surprised if this weren't the only point of friction. #9901 is much appreciated (as is all your DWARF work, thank you!) and please feel free to call out any other issues you see!
Last updated: Jan 24 2025 at 00:11 UTC