You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When Rust panics, the #[track_caller] directive on a function ensures the stack trace is not reported.
Since we only return the last line of the stack when a contract aborts in wasm, we want it to be an important one. I often have seen a subtraction underflow on src/math.rs: 128 or such. Which tells me where in the cosmwasm-std it panics (obvious from the message), but nothing about where in the contract it was.
It would be good to investigate if #[track_caller] plays well with our abort callback and if so, add this to some lower-level math functions that panic, so we are likely to get a contract line number on math errors, not internal lines.
BTW, I took a look at the rust docs to see how this would affect the wasm panic handler and was left confused and amazed once again at the complexity of the rust compiler.
The text was updated successfully, but these errors were encountered:
When Rust panics, the
#[track_caller]
directive on a function ensures the stack trace is not reported.Since we only return the last line of the stack when a contract aborts in wasm, we want it to be an important one. I often have seen a subtraction underflow on
src/math.rs: 128
or such. Which tells me where in the cosmwasm-std it panics (obvious from the message), but nothing about where in the contract it was.It would be good to investigate if
#[track_caller]
plays well with our abort callback and if so, add this to some lower-level math functions that panic, so we are likely to get a contract line number on math errors, not internal lines.BTW, I took a look at the rust docs to see how this would affect the wasm panic handler and was left confused and amazed once again at the complexity of the rust compiler.
The text was updated successfully, but these errors were encountered: