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

iwasm doesn't respect timeout in start function execution #4047

Open
sjamesr opened this issue Jan 22, 2025 · 7 comments
Open

iwasm doesn't respect timeout in start function execution #4047

sjamesr opened this issue Jan 22, 2025 · 7 comments

Comments

@sjamesr
Copy link
Contributor

sjamesr commented Jan 22, 2025

Let's say you run

iwasm --timeout=4000 foo.wasm

If foo.wasm has a start function with an infinite loop (e.g. due to a bug), the intepreter is not able to interrupt execution after 4 seconds. The interpreter will try to interrupt modules by calling wasm_runtime_terminate, but this requires a module instance, and obviously in this case module instantiation cannot finish.

What do you all think of adding some mechanism to interrupt the start function after a period of time? Is there a way to do this that I'm missing?

@lum1n0us
Copy link
Collaborator

🤔 Something like #2163 and #3927

@hovertank3d
Copy link

I don't know how it's done in similar projects(like gas metering from wasmtime mentioned above), but i think adding parameter limiting control instructions(or limiting call nesting) would be probably a solution for things like infinite loops

@lum1n0us
Copy link
Collaborator

lum1n0us commented Feb 9, 2025

like --fuel of wasm-tools smith?

  -f, --fuel <FUEL>
          The default amount of fuel used with `--ensure-termination`.
          
          This is roughly the number of loop iterations and function calls that will be executed before a trap is raised to prevent infinite loops.

@hovertank3d
Copy link

hovertank3d commented Feb 9, 2025

"roughly the number of loop iterations and function calls"
Oh, yes, i meant exactly that!

@yamt
Copy link
Collaborator

yamt commented Feb 10, 2025

Let's say you run

iwasm --timeout=4000 foo.wasm

If foo.wasm has a start function with an infinite loop (e.g. due to a bug), the intepreter is not able to interrupt execution after 4 seconds. The interpreter will try to interrupt modules by calling wasm_runtime_terminate, but this requires a module instance, and obviously in this case module instantiation cannot finish.

What do you all think of adding some mechanism to interrupt the start function after a period of time? Is there a way to do this that I'm missing?

you are right it's impossible with the current api to terminate instances in that state.

a possible solution is to separate the instantiation to two steps, similarly to:
https://github.com/yamt/toywasm/blob/6cdb84116abb930e903221231dd657ec08fec9e2/lib/instance.h#L31-L45

@sjamesr
Copy link
Contributor Author

sjamesr commented Feb 10, 2025

#4072

Demo:

$ ./iwasm --timeout=4000 /tmp/out.wasm          # out.wasm has a start func with an infinite loop
WASM module instantiate failed: Exception: terminated by user    # happens 4s later

sjamesr added a commit to sjamesr/wasm-micro-runtime that referenced this issue Feb 10, 2025
Tries to address
bytecodealliance#4047.

Before this change, wasm_runtime_instantiate would execute the start
function unconditionally, correctly implementing the spec. However, if
there is an infinite loop in the start function, there was no way to
interrupt execution.

This change introduces a parameter to InstantiationArgs indicating
whether the start function should be immediately invoked. If not,
wasm_runtime_instantiate returns a module instance that is initialized
except for the start function.

This change adds a wasm_runtime_instantiate_run_start_func function
which performs this last instantiation step. The user may prepare a
timeout in advance of calling this to guard against expensive/infinite
loops.

This change also demonstrates a possible technique for doing this in
iwasm.c.
@sjamesr
Copy link
Contributor Author

sjamesr commented Feb 10, 2025

I don't know what to do in the multi-module case, presumably all start functions have to be deferred until the user calls run_start_func on the root module. But before I started solving that, I just wanted to know what everybody thought of the approach in general.

sjamesr added a commit to sjamesr/wasm-micro-runtime that referenced this issue Feb 10, 2025
Tries to address
bytecodealliance#4047.

Before this change, wasm_runtime_instantiate would execute the start
function unconditionally, correctly implementing the spec. However, if
there is an infinite loop in the start function, there was no way to
interrupt execution.

This change introduces a parameter to InstantiationArgs indicating
whether the start function should be immediately invoked. If not,
wasm_runtime_instantiate returns a module instance that is initialized
except for the start function.

This change adds a wasm_runtime_instantiate_run_start_func function
which performs this last instantiation step. The user may prepare a
timeout in advance of calling this to guard against expensive/infinite
loops.

This change also demonstrates a possible technique for doing this in
iwasm.c.
sjamesr added a commit to sjamesr/wasm-micro-runtime that referenced this issue Feb 10, 2025
Tries to address
bytecodealliance#4047.

Before this change, wasm_runtime_instantiate would execute the start
function unconditionally, correctly implementing the spec. However, if
there is an infinite loop in the start function, there was no way to
interrupt execution.

This change introduces a parameter to InstantiationArgs indicating
whether the start function should be immediately invoked. If not,
wasm_runtime_instantiate returns a module instance that is initialized
except for the start function.

This change adds a wasm_runtime_instantiate_run_start_func function
which performs this last instantiation step. The user may prepare a
timeout in advance of calling this to guard against expensive/infinite
loops.

This change also demonstrates a possible technique for doing this in
iwasm.c.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants