0x-mesh
                                
                                 0x-mesh copied to clipboard
                                
                                    0x-mesh copied to clipboard
                            
                            
                            
                        RuntimeError: memory access out of bounds
Context
Please provide any relevant information about your setup
- Are you running Mesh in the browser or as a standalone server? Are running Mesh inside of Docker or directly running the binary?
In the browser.
- What version of Mesh are you running? Be as specific as possible (e.g., 8.0.1instead oflatestor8).
@pgebheim can you confirm the version?
Expected Behavior
Mesh should run in the browser.
Current Behavior
Very occasionally, we see RuntimeError: memory access out of bounds. This was most recently reported by Augur. The bug seems to be extremely rare and we have multiple reports of running Mesh in the browser for hours without seeing it pop up.
This was supposed to be fixed by https://github.com/0xProject/0x-mesh/pull/834 but apparently is still around. One possible fix is to replace github.com/sirupsen/logrus with our own logging library.
Failure Information (for bugs)

Steps to Reproduce
We aren't actually sure what steps trigger the error.
We can reproduce this by setting verbosity to 6 (trace) in `packages/mesh-webpack-example/src/index.ts
Goroutines running at a crash:
wasm_exec.js:65 
runtime stack:
wasm_exec.js:65 runtime.throw(0x1dcf94, 0x11)
wasm_exec.js:65 	/Users/mason/.go/src/runtime/panic.go:1116 +0x7
wasm_exec.js:65 runtime.gentraceback(0xffffffffffffffff, 0xffffffffffffffff, 0x0, 0x1001380, 0x0, 0x0, 0x7fffffff, 0x33ffe8, 0xdc84c8, 0x0, ...)
wasm_exec.js:65 	/Users/mason/.go/src/runtime/traceback.go:273 +0x172
wasm_exec.js:65 runtime.copystack(0x1001380, 0x800)
wasm_exec.js:65 	/Users/mason/.go/src/runtime/stack.go:888 +0x17
wasm_exec.js:65 runtime.shrinkstack(0x1001380)
wasm_exec.js:65 	/Users/mason/.go/src/runtime/stack.go:1141 +0x22
wasm_exec.js:65 runtime.scanstack(0x1001380, 0x101f698)
wasm_exec.js:65 	/Users/mason/.go/src/runtime/mgcmark.go:710 +0x56
wasm_exec.js:65 runtime.markroot.func1()
wasm_exec.js:65 	/Users/mason/.go/src/runtime/mgcmark.go:226 +0xc
wasm_exec.js:65 runtime.markroot(0x101f698, 0xe)
wasm_exec.js:65 	/Users/mason/.go/src/runtime/mgcmark.go:199 +0x21
wasm_exec.js:65 runtime.gcDrain(0x101f698, 0x7)
wasm_exec.js:65 	/Users/mason/.go/src/runtime/mgcmark.go:999 +0x13
wasm_exec.js:65 runtime.gcBgMarkWorker.func2()
wasm_exec.js:65 	/Users/mason/.go/src/runtime/mgc.go:1963 +0x2e
wasm_exec.js:65 runtime.systemstack(0xdc89c0)
wasm_exec.js:65 	/Users/mason/.go/src/runtime/asm_wasm.s:166 +0x2
wasm_exec.js:65 runtime.mstart()
wasm_exec.js:65 	/Users/mason/.go/src/runtime/proc.go:1041
wasm_exec.js:65 
wasm_exec.js:65 goroutine 10 [GC worker (idle)]:
wasm_exec.js:65 runtime.systemstack_switch()
wasm_exec.js:65 	/Users/mason/.go/src/runtime/asm_wasm.s:177 fp=0x1031760 sp=0x1031758 pc=0x13ca0000
wasm_exec.js:65 runtime.gcBgMarkWorker(0x101e000)
wasm_exec.js:65 	/Users/mason/.go/src/runtime/mgc.go:1927 +0x31 fp=0x10317d8 sp=0x1031760 pc=0x112e0031
wasm_exec.js:65 runtime.goexit()
wasm_exec.js:65 	/Users/mason/.go/src/runtime/asm_wasm.s:428 +0x1 fp=0x10317e0 sp=0x10317d8 pc=0x13f30001
wasm_exec.js:65 created by runtime.gcBgMarkStartWorkers
wasm_exec.js:65 	/Users/mason/.go/src/runtime/mgc.go:1821 +0xa
wasm_exec.js:65 
wasm_exec.js:65 goroutine 1 [select (no cases), 2 minutes]:
wasm_exec.js:65 main.main()
wasm_exec.js:65 	/Users/mason/Desktop/0x-mesh/packages/mesh-browser/go/mesh-browser/main.go:34 +0x3
wasm_exec.js:65 
wasm_exec.js:65 goroutine 6 [select, 2 minutes]:
wasm_exec.js:65 github.com/ipfs/go-log/writer.(*MirrorWriter).logRoutine(0x10da360)
wasm_exec.js:65 	/Users/mason/go/pkg/mod/github.com/ipfs/[email protected]/writer/writer.go:76 +0x8
wasm_exec.js:65 created by github.com/ipfs/go-log/writer.NewMirrorWriter
wasm_exec.js:65 	/Users/mason/go/pkg/mod/github.com/ipfs/[email protected]/writer/writer.go:41 +0x7
wasm_exec.js:65 
wasm_exec.js:65 goroutine 7 [select]:
wasm_exec.js:65 go.opencensus.io/stats/view.(*worker).start(0x10386e0)
wasm_exec.js:65 	/Users/mason/go/pkg/mod/[email protected]/stats/view/worker.go:154 +0x9
wasm_exec.js:65 created by go.opencensus.io/stats/view.init.0
wasm_exec.js:65 	/Users/mason/go/pkg/mod/[email protected]/stats/view/worker.go:32 +0x5
wasm_exec.js:65 
wasm_exec.js:65 goroutine 8 [waiting (scan)]:
wasm_exec.js:65 fatal error: unexpected signal during runtime execution
wasm_exec.js:65 panic during panic
wasm_exec.js:65 ```
We think this may be due to an underlying issue with Go and WebAssembly. See https://github.com/golang/go/issues/40081.
Ah this would make sense why lowering the log level would help! I feel pretty good about it currently since it's only happened once with the lower log level.