Skip to content

WASM/Fast: print a message in the debug channel on failure

Pierrick Couderc requested to merge picdc@wasm-fast-exec-warn-unreachable into master

Context

When the evaluation fails for any reason the Fast Execution fallbacks to the PVM to ensure the error is kernel related and not an issue with Wasmer. From the user perspective it looks like kernel_run is run twice since the debug messages are printed twice.

The message could be better or make the distinction between the two executions clearer (I'm not an ASCII-art expert). This is clearly a request for comments, I'm not sure how we can improve this UX.

Manually testing the MR

Take this kernel and an empty input file ([[]]) that prints a messagetest_kernel.wasm and panic, and run in in the debugger without and with the patch (unfortunately, the panic handler prints the message without forcing a new line at the end):

> load inputs
Loaded 0 inputs at level 0
> step inbox
This kernel will fail
Kernel panic Some("Let's panic now") at Some(Location { file: "src/lib.rs", line: 7, col: 5 })This kernel will fail
Kernel panic Some("Let's panic now") at Some(Location { file: "src/lib.rs", line: 7, col: 5 })Evaluation took 11000000000 ticks so far
Status: Waiting for input
Internal_status: Collect

then with the patch:

> load inputs
Loaded 0 inputs at level 0
> step inbox
This kernel will fail
Kernel panic Some("Let's panic now") at Some(Location { file: "src/lib.rs", line: 7, col: 5 })Evaluation failed in Fast Execution, restarting the current `kernel_run` execution with the PVM Interpreter.
This kernel will fail
Kernel panic Some("Let's panic now") at Some(Location { file: "src/lib.rs", line: 7, col: 5 })Evaluation took 11000000000 ticks so far
Status: Waiting for input
Internal_status: Collect

Checklist

  • Document the interface of any function added or modified (see the coding guidelines)
  • Document any change to the user interface, including configuration parameters (see node configuration)
  • Provide automatic testing (see the testing guide).
  • For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
  • Select suitable reviewers using the Reviewers field below.
  • Select as Assignee the next person who should take action on that MR
Edited by Pierrick Couderc

Merge request reports