wasm debug build crashes about wazero

[mathetake]

Sorry this didn't reproduce, and not sure what you meant by "crash".

I tried to run both arm64 and x86 with or without --release flag for both Darwin and Linux, yet finishes without apparent problems.

mathetake@lima-x86:/Users/mathetake/wazero/wazero_crash$ go run ./cmd -release -skipbuild
go: downloading github.com/tetratelabs/wazero v1.7.0
2024/05/09 12:06:13 6 funcs exported:
2024/05/09 12:06:13   deallocate: 2 params
2024/05/09 12:06:13   _start: 0 params
2024/05/09 12:06:13   __main_void: 0 params
2024/05/09 12:06:13   regex: 2 params
2024/05/09 12:06:13   ac: 2 params
2024/05/09 12:06:13   allocate: 1 params
2024/05/09 12:06:13 [1]
2024/05/09 12:06:13 [1]
mathetake@lima-x86:/Users/mathetake/wazero/wazero_crash$ go run ./cmd -skipbuild
2024/05/09 12:06:38 6 funcs exported:
2024/05/09 12:06:38   _start: 0 params
2024/05/09 12:06:38   __main_void: 0 params
2024/05/09 12:06:38   regex: 2 params
2024/05/09 12:06:38   ac: 2 params
2024/05/09 12:06:38   allocate: 1 params
2024/05/09 12:06:38   deallocate: 2 params
2024/05/09 12:06:38 [1]
2024/05/09 12:06:38 [1]
mathetake@lima-x86:/Users/mathetake/wazero/wazero_crash$ uname -a
Linux lima-x86 6.5.0-28-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 28 23:46:48 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

[mathetake]

if you still believe it "crashes", I would appreciate it if you setup the repository and give us the failing github action job.

[mark-pictor-csec]

Well that's unfortunate. Thanks for taking a look.

setup the repository and give us the failing github action job.

I'm guessing you mean fork the repo, enable ci, and add test with wasm that fails?
I'll see about doing so and also verify that this isn't osx specific.

[ncruces]

It doesn't need to be a fork of this repo. Just your repo, with your code, that depends on wazero, and an action that shows your crash. That would be incredibly helpful.

[mark-pictor-csec]

@mathetake @ncruces
I finally found time to work on this more. See the run wasm debug step in the failed action.

call regex(): wasm error: unreachable
wasm stack trace:
	wazero_crash_lib-4cb0c7a6ebcbc518.wasm.abort()
	wazero_crash_lib-4cb0c7a6ebcbc518.wasm._ZN3std3sys3pal4wasi7helpers14abort_internal[17](https://github.com/mark-pictor-csec/wazero_rust_crash/actions/runs/9133849827/job/25118191937#step:14:18)h05344e3339eea616E()
		0x353f05: /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys/pal/wasi/helpers.rs:107:14
        [ ... ]

[mathetake]

great, thank you for your time. I see it only reaches unreachable with debug build. Does that happen with interpreter? Also, could you update to 1.7.2 and see if it is fixed or not?

[mathetake]

I am sorry this happens for all amd64, arm64 and interpreter and don't think this is a bug of wazero. 99% sure that your bug existing in https://github.com/mark-pictor-csec/wazero_rust_crash/blob/main/cmd/main.go#L113-L140

how can you be sure that the pointer escaped in the cleanup closure is alive until the end? That's where debug vs release difference creeps in i thinl.

[mark-pictor-csec]

I don't think the pointer's liveness could have any effect here. The error comes from (api.Function).Call(), before the deferred cleanup could run. Note the first line printed in the error:

call regex(): wasm error: unreachable

matching the log statement in main.go:L120..L123:

	res, err := m.Call(ctx, ptr, uint64(len(s)))
	if err != nil {
		log.Fatalf("call regex(): %s", err)
	}

[mark-pictor-csec]

ugh... found a mistake in my code. I'll fix it and get back to you