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.

Sign up for GitHub

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

Jump to bottom

Skip trap handling while executing imports #866

Closed
avasylev opened this issue Oct 7, 2019 · 6 comments
Closed

Skip trap handling while executing imports #866

avasylev opened this issue Oct 7, 2019 · 6 comments
Labels
🎉 enhancement New feature!

Comments

@avasylev
Copy link

avasylev commented Oct 7, 2019 •
edited
Loading

Motivation

Currently when embedding wasmer it's trap catches errors generated in imports code. These are not in wasm code and are not safe to handle by wasmer trap. Error message doesn't have clear indication if error was in wasm code or import, thus making it unsafe to continue execution after any trap.

Proposed solution

Track wasm code / imports execution, and only handle trap when it was triggered from wasm code. Something like https://goo.gl/yMeyUY
@avasylev avasylev added the 🎉 enhancement New feature! label Oct 7, 2019
@nlewycky
Copy link
Contributor

Thanks for the feature request.

I'm a little confused what you mean by "generated in imports code" which are "not in wasm code". What imports are you referring to, if not WAsm imports?

Setting aside imports, if you mean traps in native code, then indeed Wasmer shouldn't take control of the process' signal handlers. Is this bug a dupe of #842 ?

@avasylev
Copy link
Author

#842 seems to be about the same issue, tracking that trap signal originated from within wasm vm boundries.

To clarify, yes I mean wasm imports, function pointer passed to wasmer_import_func_new. When such function is implemented in C++ (native, not wasm) and it triggers trap, wasmer should not catch such trap, but let it buble and crash the process (let host handler deal with trap).

@nlewycky
Copy link
Contributor

nlewycky commented Oct 18, 2019 •
edited
Loading

Got it! Yes, this will be fixed when we fix #842.

@nlewycky
Copy link
Contributor

Duplicate of #842

@nlewycky nlewycky marked this as a duplicate of #842 Oct 18, 2019
losfair pushed a commit that referenced this issue Nov 10, 2019
@bors @dependabot-preview
Merge #808
0ea5b1b 
808: Bump rand from 0.7.0 to 0.7.2 r=MarkMcCaskey a=dependabot-preview[bot]

Bumps [rand](https://github.com/rust-random/rand) from 0.7.0 to 0.7.2.
<details>
<summary>Changelog</summary>

*Sourced from [rand's changelog](https://github.com/rust-random/rand/blob/master/CHANGELOG.md).*

> ## [0.7.2] - 2019-09-16
> ### Fixes
> - Fix dependency on `rand_core` 0.5.1 ([#890](https://github-redirect.dependabot.com/rust-random/rand/issues/890))
> 
> ### Additions
> - Unit tests for value stability of distributions added ([#888](https://github-redirect.dependabot.com/rust-random/rand/issues/888))
> 
> ## [0.7.1] - 2019-09-13
> ### Fixes
> - Fix `no_std` behaviour, appropriately enable c2-chacha's `std` feature ([#844](https://github-redirect.dependabot.com/rust-random/rand/issues/844))
> - `alloc` feature in `no_std` is available since Rust 1.36 ([#856](https://github-redirect.dependabot.com/rust-random/rand/issues/856))
> - Fix or squelch issues from Clippy lints ([#840](https://github-redirect.dependabot.com/rust-random/rand/issues/840))
> 
> ### Additions
> - Add a `no_std` target to CI to continously evaluate `no_std` status ([#844](https://github-redirect.dependabot.com/rust-random/rand/issues/844))
> - `WeightedIndex`: allow adjusting a sub-set of weights ([#866](https://github-redirect.dependabot.com/rust-random/rand/issues/866))
</details>
<details>
<summary>Commits</summary>

- [`249ebfc`](rust-random/rand@249ebfc) Merge pull request [#888](https://github-redirect.dependabot.com/rust-random/rand/issues/888) from dhardy/master
- [`5ac4cbd`](rust-random/rand@5ac4cbd) Prepare rand 0.7.2
- [`f39915a`](rust-random/rand@f39915a) rand_distr: work around tan func issue
- [`802ba8f`](rust-random/rand@802ba8f) rand_distr: add missing value_stability tests
- [`a43d7f1`](rust-random/rand@a43d7f1) Fix tests
- [`2ef2e66`](rust-random/rand@2ef2e66) Add value_stability tests for uniform
- [`096a5dd`](rust-random/rand@096a5dd) UniformSampler: add doc on usage of sample_single
- [`f78781a`](rust-random/rand@f78781a) Uniform: replace inner field with struct tuple
- [`856fdfb`](rust-random/rand@856fdfb) Distribution: add doc of portability
- [`72af6f8`](rust-random/rand@72af6f8) Add value_stability tests for bernoulli, int, float and other distrs
- Additional commits viewable in [compare view](rust-random/rand@0.7.0...0.7.2)
</details>
<br />

[![Dependabot compatibility score](https://api.dependabot.com/badges/compatibility_score?dependency-name=rand&package-manager=cargo&previous-version=0.7.0&new-version=0.7.2)](https://dependabot.com/compatibility-score.html?dependency-name=rand&package-manager=cargo&previous-version=0.7.0&new-version=0.7.2)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Pull request limits (per update run and/or open at any time)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)

Finally, you can contact us by mentioning @dependabot.

</details>

Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>
@syrusakbary
Copy link
Member

This should be solved in the refactor.

@syrusakbary
Copy link
Member

We just landed the refactor in master. Closing the issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
🎉 enhancement New feature!
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@syrusakbary @nlewycky @avasylev