Comments (9)
reproduced on my local m1 mac
~/wazero/internal/integration_test/libsodium
$ go test -bench='BenchmarkLibsodium/box_seal' -count=100 -benchtime=10x
goos: darwin
goarch: arm64
pkg: github.com/tetratelabs/wazero/internal/integration_test/libsodium
BenchmarkLibsodium/box_seal-10 10 506911971 ns/op
BenchmarkLibsodium/box_seal-10 10 504660892 ns/op
BenchmarkLibsodium/box_seal-10 10 502820754 ns/op
BenchmarkLibsodium/box_seal-10 10 507620717 ns/op
BenchmarkLibsodium/box_seal-10 10 510368371 ns/op
BenchmarkLibsodium/box_seal-10 10 508002408 ns/op
BenchmarkLibsodium/box_seal-10 10 513437050 ns/op
BenchmarkLibsodium/box_seal-10 --- FAIL: BenchmarkLibsodium/box_seal-10
require.go:331: expected no error, but was module[] function[_start] failed: wasm error: unreachable
wasm stack trace:
.$83(i32,i32)
.$9()
/Users/mathetake/wazero/internal/integration_test/libsodium/bench_test.go:133
/usr/local/go/src/testing/benchmark.go:193
/usr/local/go/src/testing/benchmark.go:288
/usr/local/go/src/runtime/asm_arm64.s:1222
BenchmarkLibsodium/box_seal-10 10 508346446 ns/op
BenchmarkLibsodium/box_seal-10 10 505010212 ns/op
BenchmarkLibsodium/box_seal-10 10 506423908 ns/op
from wazero.
turns out it's flaky - rerun succeeded
from wazero.
turns out this happens with v1.7.0 as well, so the bug might have existed in the first place
from wazero.
maybe next is to see if this will happen with interpreter or amd64, but I have no cycle right now
from wazero.
not sure if this happens with the old compiler in the first place
from wazero.
I was able to reproduce it with amd64
:
$ go test -bench='BenchmarkLibsodium/box_seal' -count=100 -benchtime=10x -v
goos: linux
goarch: amd64
pkg: github.com/tetratelabs/wazero/internal/integration_test/libsodium
cpu: AMD EPYC 7B13
BenchmarkLibsodium
BenchmarkLibsodium/box_seal
require.go:331: expected no error, but was module[] function[_start] failed: wasm error: unreachable
wasm stack trace:
.$83(i32,i32)
.$9()
/home/cruces/Documents/Personal/wazero/internal/integration_test/libsodium/bench_test.go:140
/usr/local/go/src/runtime/asm_amd64.s:1695
^Csignal: interrupt
--- FAIL: BenchmarkLibsodium/box_seal-48
FAIL github.com/tetratelabs/wazero/internal/integration_test/libsodium 34.403s
Ignore the line number. I modified the benchmark to run multiple copies over runtime.NumCPU()
.
I was also able to reproduce it with the interpreter (with a lot more effort):
$ go test -bench='BenchmarkLibsodium/box_seal' -count=100 -benchtime=10x -v
goos: linux
goarch: amd64
pkg: github.com/tetratelabs/wazero/internal/integration_test/libsodium
cpu: AMD EPYC 7B13
BenchmarkLibsodium
BenchmarkLibsodium/box_seal
require.go:331: expected no error, but was module[] function[_start] failed: wasm error: unreachable
wasm stack trace:
.$83(i32,i32)
.$9()
/home/cruces/Documents/Personal/wazero/internal/integration_test/libsodium/bench_test.go:140
/usr/local/go/src/runtime/asm_amd64.s:1695
^Csignal: interrupt
FAIL github.com/tetratelabs/wazero/internal/integration_test/libsodium 617.368s
from wazero.
It also seems to happen with the old, 1.6.0, compliler:
$ go test -bench='BenchmarkLibsodium/box_seal' -count=100 -benchtime=10x -v
goos: linux
goarch: amd64
pkg: github.com/tetratelabs/wazero/internal/integration_test/libsodium
cpu: AMD EPYC 7B13
BenchmarkLibsodium
BenchmarkLibsodium/box_seal
require.go:331: expected no error, but was module[] function[_start] failed: wasm error: unreachable
wasm stack trace:
.$83(i32,i32)
.$9()
/home/cruces/Documents/Personal/wazero/internal/integration_test/libsodium/bench_test.go:140
/usr/local/go/src/runtime/asm_amd64.s:1695
--- FAIL: BenchmarkLibsodium/box_seal
--- FAIL: BenchmarkLibsodium
FAIL
exit status 1
FAIL github.com/tetratelabs/wazero/internal/integration_test/libsodium 9.488s
from wazero.
thank you for your research @ncruces. I think we can conclude that this is some flake in the binary in the first place, I still wonder where does it come from though given that the binary is not compiled with threads
from wazero.
Well, it imports (and calls) random_get
, so there's plenty of room for non-determinism in there.
$ wasm-dis box_seal.wasm | grep '(import'
(import "wasi_snapshot_preview1" "clock_time_get" (func $fimport$0 (param i32 i64 i32) (result i32)))
(import "wasi_snapshot_preview1" "fd_close" (func $fimport$1 (param i32) (result i32)))
(import "wasi_snapshot_preview1" "fd_fdstat_get" (func $fimport$2 (param i32 i32) (result i32)))
(import "wasi_snapshot_preview1" "fd_seek" (func $fimport$3 (param i32 i64 i32 i32) (result i32)))
(import "wasi_snapshot_preview1" "fd_write" (func $fimport$4 (param i32 i32 i32 i32) (result i32)))
(import "wasi_snapshot_preview1" "poll_oneoff" (func $fimport$5 (param i32 i32 i32 i32) (result i32)))
(import "wasi_snapshot_preview1" "proc_exit" (func $fimport$6 (param i32)))
(import "wasi_snapshot_preview1" "random_get" (func $fimport$7 (param i32 i32) (result i32)))
from wazero.
Related Issues (20)
- Plans to support component model? HOT 4
- wasm debug build crashes HOT 9
- performance issue in browser environment HOT 3
- [help want] the program is hangup when read my net file system HOT 1
- [Question] Compilation cache over different versions HOT 1
- `unreachable` error and stack trace if compiled and extra memory, not otherwise HOT 4
- Clarification on concurrency semantics for invocations HOT 2
- `path_open` with an empty path should fail
- `path_symlink` doesn't work HOT 1
- flaky test: TestEngine_sortedCompiledModules
- Should not be able to open a directory with write
- Path normalization causes more accepted file paths HOT 2
- [Question] How to resolve these imports required by wasm runtime HOT 4
- Panic when calling `ExportedFunction` with WASI function name HOT 1
- Representative benchmarks of wazero for Go compiler perf measurement HOT 9
- Data race in Memory.Grow with concurrency HOT 1
- Standard `os` package test for Go 1.23rc1 is failing on Windows HOT 3
- WASI Preview 2 support HOT 4
- How to use HostFunctionBuilder with multiple goroutines? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wazero.