abrown opened PR #7220 from abrown:log-wait-notify
to bytecodealliance:main
:
When troubleshooting deadlocks in WebAssembly modules, it is important to understand which
wait
instructions are still pending anotify
. It would be nice to have some kind of--warn-deadlock-after=1s
flag available that would poll the parking lot forwait
s hanging past the time limit, but I realized the real value would be to tie thewait
instruction (through CLIF) to the original source code, if debug information were available. This did not seem to be entirely feasible, since CLIF loses the original Wasm source context (is this true?) and I was not confident that we would be able to useaddr2line
to map from Wasm instructions to source (e.g., see @cfallin's
issue).Instead, this change simply logs each valid
wait
andnotify
execution, leaving it to the user to figure out which one is hanging (should not be too difficult) and how to map this back to their source code (more difficult).<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
abrown edited PR #7220:
When troubleshooting deadlocks in WebAssembly modules, it is important to understand which
wait
instructions are still pending anotify
. It would be nice to have some kind of--warn-deadlock-after=1s
flag available that would poll the parking lot forwait
s hanging past the time limit, but I realized the real value would be to tie thewait
instruction (through CLIF) to the original source code, if debug information were available. This did not seem to be entirely feasible, since CLIF loses the original Wasm source context (is this true?) and I was not confident that we would be able to useaddr2line
to map from Wasm instructions to source (e.g., see @cfallin's issue).Instead, this change simply logs each valid
wait
andnotify
execution, leaving it to the user to figure out which one is hanging (should not be too difficult) and how to map this back to their source code (more difficult).<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
abrown has marked PR #7220 as ready for review.
abrown requested wasmtime-core-reviewers for a review on PR #7220.
abrown requested pchickey for a review on PR #7220.
pchickey submitted PR review:
lgtm, modulo a style change across all of these traces
pchickey submitted PR review:
lgtm, modulo a style change across all of these traces
pchickey created PR review comment:
instead of using the format string, use
log::trace!("memory.atomic.notify", addr=addr_index, count=count);
to provide structured values.
abrown submitted PR review.
abrown created PR review comment:
I tried that but it complains: I think to use the key-value syntax we need to set
target: ...,
up front and still provide a string at the end (seelog::log!
)?
pchickey submitted PR review.
pchickey created PR review comment:
oh, my bad. I just realized this is
log
and the key value syntax only works with thetracing
crate, and I forgot we uselog
in wasmtime-runtime in order to keep the dependencies as small as possible, buttracing
in wasmtime-wit-bindgen, wasi, etc.So, your PR is good to go as is. I don't think we need should using
log
vstracing
down in the runtime now, unless someone really wants to.
pchickey submitted PR review.
abrown merged PR #7220.
Last updated: Nov 22 2024 at 16:03 UTC