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

Runtime error: wasm async call execution failed with error: PrepareError("Gas instrumentation failed.") #1344

Closed
vgrichina opened this issue Sep 24, 2019 · 5 comments
Assignees
Labels
A-transaction-runtime Area: transaction runtime (transaction and receipts processing, state transition, etc)
Milestone

Comments

@vgrichina
Copy link
Collaborator

vgrichina commented Sep 24, 2019

See nearprotocol/assemblyscript#73 for context

When floats are detected error should be explicit about floats. Same goes for any other banned instruction type. Parity's gas metering injection code is relatively easy to fix to return specific error instead of general one.

it should be possible to return detailed error from here:
https://github.com/paritytech/wasm-utils/blob/c9cdef4c517b4da997d8ed518575a5524b3f3a86/src/rules.rs#L294

looks like https://github.com/paritytech/wasm-utils/blob/c9cdef4c517b4da997d8ed518575a5524b3f3a86/src/rules.rs#L308 tracks instruction types

@bowenwang1996
Copy link
Collaborator

It is not trivial. We basically have to patch the library the same way we are doing the error propagation in nearcore. It might involve a lot of work.

@vgrichina
Copy link
Collaborator Author

@bowenwang1996 maybe I don't understand something with Rust, but why is it any more complex than instead of having empty payload in Err(())we give payload with more info about specific error?

@bowenwang1996
Copy link
Collaborator

The problem is that every error inside that library is consumed. So it is hard to get the error we want without properly propagating the errors. But actually I think it might not be too hard if we just want to see whether it is caused by floats, although it feels like a hack

@vgrichina
Copy link
Collaborator Author

But actually I think it might not be too hard if we just want to see whether it is caused by floats, although it feels like a hack

no need to do some beautiful solution, we just need to have reasonable error message for developers for this specific case (and maybe other common cases).

@MaksymZavershynskyi
Copy link
Contributor

Floats are now enabled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-transaction-runtime Area: transaction runtime (transaction and receipts processing, state transition, etc)
Projects
None yet
Development

No branches or pull requests

5 participants