Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#BUG# runtime error: nil pointer dereference (WASI) #3798

Open
vnaki opened this issue Jun 18, 2023 · 6 comments
Open

#BUG# runtime error: nil pointer dereference (WASI) #3798

vnaki opened this issue Jun 18, 2023 · 6 comments
Labels
enhancement New feature or request wasm WebAssembly

Comments

@vnaki
Copy link

vnaki commented Jun 18, 2023

wasi output error:

panic: runtime error: nil pointer dereference
panic: unreachable

TinyGo version:

tinygo version 0.28.1 darwin/amd64 (using go version go1.20.1 and LLVM version 15.0.0)

Command line:

tinygo build -o wasi.wasm -target=wasi main.go

Here 2 cases:

//export run
func run() {
  var wg = new(sync.WaitGroup)
  go func() {
     println("goroutine")
     wg.Done()
  }()
  wg.Add(1)  // here error occur
  wg.Wait()
}

or

//export run
func run() {
   time.Sleep(time.Second)
}

Errors will occur above!

@vnaki vnaki changed the title runtime error: nil pointer dereference (WASI) #BUG# runtime error: nil pointer dereference (WASI) Jun 18, 2023
@dgryski
Copy link
Member

dgryski commented Jul 4, 2023

This is basically #2735 ; the runtime isn't initialized.

@deadprogram deadprogram added duplicate This issue or pull request already exists wasm WebAssembly and removed duplicate This issue or pull request already exists labels Jul 27, 2023
@deadprogram
Copy link
Member

@dgryski are you sure you meant #2735 ?

@deadprogram
Copy link
Member

I actually just ran into this myself, and finally understand what @dgryski was saying.

If nothing has has yet called the _start() function then the runtime is not yet initialized. So WASI programs that do everything from their init() function can run into this if they try to do anything outside the main goroutine.

Here is another example of the same problem fermyon/spin#1259 (comment)

I tried the naive solution of just adding a call to _start() from the init() function here https://github.com/tinygo-org/tinygo/blob/dev/src/runtime/runtime_wasm_wasi.go#L30 but that did not appear to have any effect.

@dgryski @aykevl or anyone else, what do you think we can do about this?

@aykevl
Copy link
Member

aykevl commented Nov 14, 2023

If nothing has has yet called the _start() function then the runtime is not yet initialized. So WASI programs that do everything from their init() function can run into this if they try to do anything outside the main goroutine.

It's much bigger than that. If _start isn't called, the runtime isn't initialized. This means the heap isn't set up, and most init functions haven't been run. Anything that does a heap allocation might crash. Or, indeed, interacts with the scheduler in any way. You really have to call _start first before calling any exported functions.

I tried the naive solution of just adding a call to _start() from the init() function here https://github.com/tinygo-org/tinygo/blob/dev/src/runtime/runtime_wasm_wasi.go#L30 but that did not appear to have any effect.

No that can't work. _start initializes the runtime, runs package initializers, and calls main. So even if _start was called, you would have introduced infinite recursion.

@dgryski
Copy link
Member

dgryski commented Nov 15, 2023

Should we come up with some supported way to initialize the runtime so that this kind of behaviour is supported?

@deadprogram
Copy link
Member

Should we come up with some supported way to initialize the runtime so that this kind of behaviour is supported?

That would be very helpful!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request wasm WebAssembly
Projects
None yet
Development

No branches or pull requests

4 participants