Null strings are always read from STDIN

[flavio]

Note well: this is a copy of bytecodealliance/wasmtime#2373, as requested here.

I've written a simple "echo" program using AssemblyScript and as-wasi. The program reads the user input from STDIN and writes it back to STDOUT.

Unfortunately it looks like I can never get back the input I enter.

• What are the steps to reproduce the issue?

This the source code of the AssemblyScript program I'm running:

import "wasi"

import {Console} from "as-wasi"

Console.log("type something");

let input: string | null;
let msg : string = "nothing";

input = Console.readAll();
if (input != null) {
  msg = input!
}

Console.log('I got: ' + msg);

The program can be compiled to a WASM binary by doing:

$ asc echo.ts -b echo.wasm

And it can be run in this way:

$ wasmtime run echo.wasm

The program will start and I'll be able to enter my text. The program will keep reading from STDIN until I send the EOF symbol (I'm on Linux -> CTRL-D).

Unfortunately the input variable is always null.

• What do you expect to happen? What does actually happen? Does it panic, and
  if so, with which assertion?

I would expect the WASM program to be able to read data from stdin. The input object should hold the text I entered on my terminal.

• Which Wasmtime version / commit hash / branch are you using?

This is my stack:

• wasmtime: 0.21.0
• AssemblyScript: 0.17.1
• as-wasi: 0.4.0

• If relevant, can you include some extra information about your environment?
  (Rust version, operating system, architecture...)

I'm running on a x86_64 Linux box that has openSUSE Tumbleweed

More information...

The as-wasi handles STDIN/STDOUT/STDERR by using instances of the Descriptor class. The library simply opens the file descriptor 0 for STDIN, 1 for STDOUT and 2 for STDERR. In my tests it looks like opening the file descriptor 0 always returns a null instance of Descriptor; this doesn't happen with STDOUT and STDERR.

The same issue happens also when running the program through a custom made Go program I wrote leveraging wasmtime-go.
In that case I even tried to start the WASM binary not by inheriting the parent STDIN, but instead by using a text file I previously created. Also in this case the WASM binary got a null object when reading from the STDIN.

Relevant: a similar WASM binary, generated by translating Rust -> WASM, just works as expected.

[flavio]

As @peterhuene commented here, this line could be the root cause of this issue.

[jedisct1]

But this line doesn't exist any more.

[jedisct1]

as-wasi: 0.4.0

Current version is 0.4.3.

[flavio]

Reading from stdin is still broken, but now it fails with a different error.

I've rebuilt the example pasted above using:

• as-wasi 0.4.3
• asc version 0.17.2

The program now fails with the following message:

$ echo hi | wasmtime run echo.wasm
type something
abort:  in ~lib/rt/pure.ts(112:14)
Error: failed to run main module `echo.wasm`

Caused by:
    0: failed to invoke command default
    1: exit with invalid exit status outside of [0..126)
       wasm backtrace:
         0:  0x555 - <unknown>!<wasm function 9>
         1:  0x1f6 - <unknown>!<wasm function 3>
         2:  0x209 - <unknown>!<wasm function 4>
         3: 0x2490 - <unknown>!<wasm function 54>
         4: 0x2584 - <unknown>!<wasm function 57>
         5: 0x25d8 - <unknown>!<wasm function 58>

[MaxGraey]

Could you share your code? Do you use any interop between wasmtime host and wasm?

[peterhuene]

It looks like something is calling proc_exit with an exit code outside of the WASI-defined acceptable range of [0..126) (granted this range isn't part of the current WASI snapshot yet, so Wasmtime is being a little overzealous with this enforcement).

[flavio]

Could you share your code? Do you use any interop between wasmtime host and wasm?

It's the same code shown in the body of the issue. If you want I can create a gist

[flavio]

@jedisct1 sorry to bother you, do you want me to open a new issue to track the proc_exit issue or can you reopen this one?

[jedisct1]

Looks like a different issue.