Wasmi execution mismatch between `v0.31.0` and `v0.32.0-beta.2`
tomaka opened this issue · comments
This is the continuation of smol-dot/smoldot#1527
As explained, I've detected a Wasm execution that doesn't produce the same result on wasmi 0.31 and 0.32. With v0.31, execution gracefully finishes, while with v0.32 an unreachable opcode is reached.
Here is a reproduction case: logs.txt
There are two Wasm function calls, and I don't know which one is problematic. I strongly suspect it's the second one, but I'm not actually certain of that. The first call starts at line 7, and the second call starts at line 2389. The two calls are completely separate and use two different Instances. The memory isn't preserved between them.
Line 1 is just for the module bytecode in hexadecimal.
Unfortunately, it's pretty hard to compare exactly wasmi 0.31 and 0.32 without some heavy modifications to my code, because the inputs change all the time. I've generated what happens with wasmi 0.31, but I haven't verified that wasmi 0.32 indeed fails. In my preliminary tests, wasmi 0.32 failed 100% of the time no matter the inputs, so the odds are high that this is the case.
I've opted for JSON so that you can easily parse it. I've manually generated the JSON (I didn't use serde for instance), I hope I didn't screw up and forget a quote for instance.
Every import of the module is simply fulfilled with a corresponding function or memory. In the case of a memory, the type of the memory we create matches what the module wants.
A "type": "write" means that the memory of the Wasm must be modified (calling Memory::data_mut and writing). The data is in hexadecimal.
A memory.grow means that we call Memory::grow.
start is when we call Func::call (where the Func comes from the exports of the wasm). The module name of the import is always env.
enter means that the wasm has called an imported function. return means that we returned from the function. So for example when a write is between an enter and a return, it means that the write happened within the imported function.
For values, the value_ty can only be i32, i64, or void. There's no floats.
@tomaka Thanks a lot for opening this issue and providing all the detailed information!
Is there information about which 2 Wasm functions of the Wasm module in line 1 have been called (indices)? I am not yet sure how useful all those logs are. I hope I can find a minimal test case.
If you're asking which exports are being called, then just search for the word start in the logs.
If you're asking which imports are being called, search for the word enter.
There are two Wasm function calls, and I don't know which one is problematic.
This is what I mean.
So I suppose one of those 2 Wasm calls in the logs is the start function, and the other is a Wasm function exported from the module? What would help me is to know the Wasm module function indices of those 2 traces of functions in the logs.
The Wasm module doesn't have a start function.
There are two individual calls in these logs because I don't know which one of the two is failing, but I strongly suspect the second one. I don't know which of the two is failing because I haven't tried wasmi 0.32.
If it's more useful I can create a repository that depends on smoldot, which you can then modify to overwrite wasmi to your local version.
Im back.
I am not sure how much this repository would help. What I need to debug are small or minimized test cases to track down the exact location. However, I have a better idea how to maybe fix this bug: I will improve the differential fuzzing further with linear memory and global mismatch detection and make another ultra long run and fix everything that pops up. I have seen similar differential fuzzing bugs in the past as the one you reported. If we are lucky this also includes the bug reported here. This fuzzing improvement needed to be done anyways.
If this does not work, I will try to get creative about this bug and see how I can fix it.
As stated in smol-dot/smoldot#1527 (comment) this issue is resolved with the release of Wasmi v0.32.0-beta.3.