Frank Rehwinkel (May 09 2024 at 22:39): Frank Rehwinkel (May 09 2024 at 22:39):Maybe everyone here knows this. I built a wasmtime from the main branch of the repo and found it could not parse Wasm components that were built with the 0.11.0 cargo-component. The error reported was Serde Deserialization Error. But building cargo-component from its main branch and rebuilding the individual components, before they were composed with wasm-tools, and then given to wasmtime fixed things.
I guess there is no binary version of the components at the moment, while things are so fluid? And of course nowhere does it say that building from main in one crate should just work with binaries being built by other crates.
Alex Crichton (May 09 2024 at 22:41):You might have actually discovered a bug I think? The binary format for components should be stable for ~1year now at this point so this isn't an expected compatibility error. Would you be able to dig in a bit more and report an issue with your findings?
fitzgen (he/him) (May 09 2024 at 22:43):the trampolines PR that landed recently doesn't change the serialized format, but does change which entries are present in it. just thinking out loud here, not sure if that would be related to what you're observing here
Frank Rehwinkel (May 09 2024 at 22:45):You mean you want me to build the components with 0.11.0 and also with cargo-component out of the tree and see what is different at the binary level?
The reproducer is super easy. I have not yet made a repo out of it, but it is the composition example that was submitted as a PR to the component-docs repo. It's all very vanilla but since I have a build script that builds the components, then runs the compose steps and then runs wasmtime on the results, it's easy to kick every time something about the tool chain is updated.
Alex Crichton (May 09 2024 at 22:45):Oh I should clarify, it's definitely the case that a version of wasmtime cannot load AOT-compiled components from a different version of wasmtime. If you're dealing with raw wasm from cargo-component, though, that should be stable
Alex Crichton (May 09 2024 at 22:46):Ah well reporting an issue is up to you, if it's difficult to reduce that's ok too. Mostly wanted to flag though that incompatibilities in the binary format of wasm are not expected at this time, so if that's what's happening that's unexpected
Frank Rehwinkel (May 09 2024 at 22:48):That is correct, I'm not compiling to machine code ahead of time. Just the *.wasm that cargo-component can build.
I bet someone gets an idea what caused this before tomorrow. If not, I'll dig into it somehow, but digging into bytealliance tools is one thing, but understanding why a serde deserialize step is reporting an error is something else. :wink:
Alex Crichton (May 09 2024 at 22:49):oh it's also ok to not reduce it too too much, if you've got instructions we can try to dig in further from there
Frank Rehwinkel (May 09 2024 at 22:50):Are there convenient places I can pick up the cargo-component binaries from the published 0.11.0 and then from main/HEAD? So I can build a reproducer that shows working and not working with binaries that everyone else could get too?
Alex Crichton (May 09 2024 at 22:51):would the releases page suffice?
Frank Rehwinkel (May 09 2024 at 22:53):If not, I guess the reproducer script can checkout the old version, built it locally, then checkout the new version in another directory, build it locally, and then run the apples to apples test. No prob.
But if I ran into it with my first try, I bet others will before tomorrow too. Anyway, I'm happy to do it tomorrow.
Frank Rehwinkel (May 09 2024 at 23:32):To spare anyone from trying what I said and not seeing it fail.
When I rebuilt the Wasm components with the binary from the 0.11.0 release (for x86_64 Darwin), it just worked. That was irksome. At least I still had copies of the Wasm binaries that didn't pass Serde Deserialization I thought.
I tried a few more things and then I remembered having rebuilt cargo-component with the --forced flag yesterday and voila! The built Wasm binaries against didn't pass muster with the latest wasmtime.
I will package this up tomorrow and get back to you.
Frank Rehwinkel (May 12 2024 at 11:58):I may have to leave this problem unresolved, but it was a very temporary one.
I have three pieces of new information but they aren't particularly helpful.
The first is even though the wasmtime that had had the serdes deserialization error was one I built from source, I was unable to recompile the wasmtime from the same directory and have it fail again. I had the earlier binary though so I could still use it to see the failure happen for other a/b tests. I tried rebuilding from the same git commit and those around it (and saw the same git hash in the reported version from the two I expected to match).
The second is even if I used the wasmtime binary that would report the serdes deserialize error for a given command.wasm file, I was unable to rebuild the command.wasm file from parts and have the new version fail. But I had the earlier command.wasm so I could always test with that too.
And third, I could take the wasmtime that would produce the failure along with the command.wasm that was needed for the failure, and run the wasmtime on the wat version of the wasm file, and that did not produce the error. So just converting the failing wasm file to a wat file allowed the wasmtime that does fail on the wasm file to succeed on the wat file.
I built the wat file by running wasm-tools print command.wasm. I don't know of a command that would go the other way, rebuild the wasm file from the wat file, so was unable to see if a rebuilt wasm would work or not work.
I thought I could diff the wat version of the failing command.wasm with the wat version of a passing command.wasm, but the only diff was the version string of the cargo-component in the various producers sections of the component files. But as both forms of wat file actually passed, I didn't know how to draw any conclusions from those differences.
I am attributing the difference to one of three things, the updated rust toolchain from one day to another, the updates to crates.io for dependencies used in the build, or my forgetting something else about the build settings or the checked out branch that I built with.
Notification Bot (May 13 2024 at 01:10):Frank Rehwinkel has marked this topic as resolved.
Last updated: Oct 23 2024 at 20:03 UTC