benchmark: Updates wazero to 1.0.0-beta.2

[codefromthecrypt]

This updates wazero to 1.0.0-beta.2

Future betas will release at least once each month until 1.0 in February 2023.

Note: Release notes will be posted in the next day or two.

Meanwhile, we've also opened a gophers slack #wazero channel for support, updates and conversation! Note: You may need an invite to join gophers.

[inkeliz]

Strangely, Zig is falling in the test. I need to investigate.

That might be two reasons:

A) karmem issue: bugs on the generated Zig code trying to read out-of-bounds contents.
B) wazero issue: some bug when read/store unaligned memory or some memory manipulation.

That issue doesn't exists in the previous version.

---

Some quick investigation:

1. Using wazero.NewRuntimeConfigInterpreter() works and pass all fuzzing.
2. Removing the Zig tests, everything else is working (https://builds.sr.ht/~inkeliz/job/834688#task-test_zig).
3. Using debug also crashes (and the trace is quite useless): https://builds.sr.ht/~inkeliz/job/834679#task-test_zig

I'll try to run some git bisect.

[inkeliz]

Using git bisect, that is the result:

git.exe bisect bad
0bd2beedac29af6aab324a50556464e32e6bdbcf is the first bad commit

tetratelabs/wazero#761

---

That is the change which causes the Zig test to fail.

[codefromthecrypt]

@inkeliz one major change in that PR is that caching exported functions is no longer supported, could that be the issue? Meanwhile, we'll look deeper.

[inkeliz]

Well, I'm using the ExportedFunctiosn with:

karmem/benchmark/main_wasi_wazero.go

Lines 106 to 109 in a75e2f0

	functions := make(map[string]api.Function, len(fn))
	for _, fn := range fn {
	functions[fn] = w.mainModule.ExportedFunction(fn)
	}

So, if that is "cache", that might be the reason. I'm re-using the same ExportedFunction:

karmem/benchmark/main_wasi_wazero.go

Lines 142 to 148 in a75e2f0

	func (w *WasmWazero) Run(s Functions, v ...uint64) ([]uint64, error) {
	f, ok := w.functions[s.String()]
	if !ok || f == nil {
	return nil, errors.New("invalid function of " + s.String())
	}
	return f.Call(context.Background(), v...)
	}

[codefromthecrypt]

same pattern in trivy, too. We need to make a call of whether to make functions lazy by default or have projects like these change their calling pattern. Meanwhile, it could be not the root cause of the memory issue.

[inkeliz]

I try it again, using:

func (w *WasmWazero) Run(s Functions, v ...uint64) ([]uint64, error) {
	f := w.mainModule.ExportedFunction(s.String())
	if f == nil {
		return nil, errors.New("invalid function of " + s.String())
	}
	return f.Call(context.Background(), v...)
}

Seems to work. So, the map[] is the issue. 🤔

[inkeliz]

However, I don't think the concurrency is the issue. I also tried to include mutex.Lock(); defer mutex.Unlock() inside the t.Fuzz(), so it will not call any function concurrently, and it doesn't work. But, I didn't investigate it deeper, just quick modifications. 😬

[codefromthecrypt]

thanks for the help @inkeliz!

[mathetake]

Thanks for you patience @inkeliz, could you try the fix here? tetratelabs/wazero#783

[codefromthecrypt]

@mathetake I added you with write. can you try on my branch?

[mathetake]

Cool will do

[inkeliz]

It's working now. 😎

[mathetake]

cool!

[codefromthecrypt]

ok now 1.0.0-beta.2 hope all good!