Stream: git-wasmtime

Topic: wasmtime / PR #2396 Fix a case of using the wrong stack m...


view this post on Zulip Wasmtime GitHub notifications bot (Nov 11 2020 at 22:49):

alexcrichton opened PR #2396 from use-right-stack-map to main:

This commit fixes an issue where when looking up the stack map for a pc
within a function we might end up reading the previous function's
stack maps. This then later caused asserts to trip because we started
interpreting random data as a VMExternRef when it wasn't. The fix was
to add None markers for "this range has no stack map" in the function
ranges map.

Closes #2386

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

Please ensure all communication adheres to the code of conduct.
-->

view this post on Zulip Wasmtime GitHub notifications bot (Nov 11 2020 at 22:50):

alexcrichton requested fitzgen for a review on PR #2396.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 11 2020 at 23:37):

fitzgen submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 11 2020 at 23:37):

fitzgen submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 11 2020 at 23:37):

fitzgen created PR Review Comment:

If info.code_offset is 0 then we could have duplicate entries (one None for the start of the function and one Some for this info).

I don't think this should ever happen though, so perhaps we can just assert that info.code_offset > 0?

The alternative is checking ahead of time whether the first info.code_offset is 0 (because they should be sorted iirc) and only adding the None entry if the first info.code_offset is not 0.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 12 2020 at 00:41):

alexcrichton updated PR #2396 from use-right-stack-map to main:

This commit fixes an issue where when looking up the stack map for a pc
within a function we might end up reading the previous function's
stack maps. This then later caused asserts to trip because we started
interpreting random data as a VMExternRef when it wasn't. The fix was
to add None markers for "this range has no stack map" in the function
ranges map.

Closes #2386

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

Please ensure all communication adheres to the code of conduct.
-->

view this post on Zulip Wasmtime GitHub notifications bot (Nov 12 2020 at 00:42):

alexcrichton submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 12 2020 at 00:42):

alexcrichton created PR Review Comment:

Oh nice catch, I refactored a bit which I think will handle this correctly, mind double-checking?

I also went ahead and did a small tweak where consecutive None entries are now coalesced.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 12 2020 at 15:05):

alexcrichton updated PR #2396 from use-right-stack-map to main:

This commit fixes an issue where when looking up the stack map for a pc
within a function we might end up reading the previous function's
stack maps. This then later caused asserts to trip because we started
interpreting random data as a VMExternRef when it wasn't. The fix was
to add None markers for "this range has no stack map" in the function
ranges map.

Closes #2386

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

Please ensure all communication adheres to the code of conduct.
-->

view this post on Zulip Wasmtime GitHub notifications bot (Nov 12 2020 at 16:26):

fitzgen submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 12 2020 at 16:26):

fitzgen submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 12 2020 at 16:26):

fitzgen created PR Review Comment:

Could make this a tiny bit less wordy (although perhaps some would argue less readable) like this:

            if !last_is_none_marker && (infos.get(0).map_or(true, |i| i.code_offset > 0) {

I would probably use map_or personally but it doesn't really matter either way.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 12 2020 at 16:27):

fitzgen submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 12 2020 at 16:27):

fitzgen created PR Review Comment:

Oh I guess this isn't actually even less wordy... nevermind!

view this post on Zulip Wasmtime GitHub notifications bot (Nov 12 2020 at 19:24):

alexcrichton merged PR #2396.


Last updated: Nov 22 2024 at 16:03 UTC