This repository has been archived by the owner on Jan 30, 2024. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 75
False positive "call stack was corrupted" warning on 0.3 #277
Closed
jonas-schievink opened this issue
Nov 15, 2021
· 4 comments
· Fixed by rust-embedded/cortex-m-rt#337
Closed
False positive "call stack was corrupted" warning on 0.3 #277
jonas-schievink opened this issue
Nov 15, 2021
· 4 comments
· Fixed by rust-embedded/cortex-m-rt#337
Labels
status: needs PR
Issue just needs a Pull Request implementing the changes
topic: unwinding
type: bug
Something isn't working
Comments
jonas-schievink
added
type: bug
Something isn't working
status: needs PR
Issue just needs a Pull Request implementing the changes
topic: unwinding
labels
Nov 15, 2021
I am also seeing this in the stm32wlxx-hal testsuite: https://github.com/stm32-rs/stm32wlxx-hal/runs/4208369937?check_suite_focus=true#step:6:33 I saw this infrequently with defmt 0.2 (difficult to reproduce, so I didn't file a bug report), but now it occurs every time with 0.3. |
I'm also hitting this on every run, along with #201.
Running this application, with |
bors bot
added a commit
to rust-embedded/cortex-m-rt
that referenced
this issue
Nov 23, 2021
337: Fix unwinding through `Reset` r=thejpster a=jonas-schievink Unwinders may detect the end of the program by seeing `0xFFFFFFFF` in `lr`, which is why code to ensure that it has that value was added in #293. However, the `bl main` overwrites that value with the current program counter. This PR saves the old `lr` value on the stack, and adds debuginfo entries to allow an external unwinder to restore the value. This fixes knurling-rs/probe-run#277 Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
A fix for this issue has gone into cortex-m-rt, but you won't see it until a) there's a new release (likely 0.7.1) or b) add a patch to Cargo.toml to use the git version. |
https://crates.io/crates/cortex-m-rt/0.7.1 is now out. |
newAM
added a commit
to stm32-rs/stm32wlxx-hal
that referenced
this issue
Nov 25, 2021
This resolves the corrupted stack backtrace in the testsuite. See knurling-rs/probe-run#277
newAM
added a commit
to stm32-rs/stm32wlxx-hal
that referenced
this issue
Nov 25, 2021
This resolves the corrupted stack backtrace in the testsuite. See knurling-rs/probe-run#277
bors bot
added a commit
that referenced
this issue
Nov 25, 2021
287: unwind: skip FDEs with initial address of 0 r=jonathanpallant a=jonas-schievink The [`panic` example in the app-template](https://github.com/knurling-rs/app-template/blob/09cb051ef0e6863e805a3fc65d509147b031f411/src/bin/panic.rs) can cause a broken backtrace like this: ``` stack backtrace: 0: 0x00001450 @ HardFaultTrampoline <exception entry> 1: 0x000008d4 @ lib::inline::__udf at ./asm/inline.rs:172:5 2: 0x000008d4 @ __udf at ./asm/lib.rs:49:17 3: 0x000001ba @ cortex_m::asm::udf at [...]/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/cortex-m-0.7.3/src/asm.rs:43:5 4: 0x000001c4 @ _defmt_panic at [...]/src/lib.rs:13:5 5: 0x000001b0 @ defmt::export::panic at [...]/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/defmt-0.3.0/src/export/mod.rs:125:14 6: 0x000001b0 @ panic::__cortex_m_rt_main at [...]/src/bin/panic.rs:10:5 7: 0x00000168 @ main at [...]/src/bin/panic.rs:6:1 8: 0x00000144 @ Reset 9: 0x00000100 @ Reset 10: 0x52205244 @ __sheap ``` This appeared to have a different cause from #277, since the fix for that didn't fix the backtrace here. After a lot of investigation, it turned out that what was going on is that there are multiple frame description entries (FDEs) in the debuginfo that claim to apply to some addresses, and we happened to pick the wrong one while unwinding from `Reset` in frame 8, causing us to restore registers incorrectly and then attempting to jump to a nonsense address. This seems to be limited to FDEs describing presumably dead code, whose base address gets reset to 0 when they're included in the final ELF, so this PR fixes it by ignoring any FDEs that claim to apply to address 0. Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
adamgreig
pushed a commit
to rust-embedded/cortex-m
that referenced
this issue
Jan 12, 2022
337: Fix unwinding through `Reset` r=thejpster a=jonas-schievink Unwinders may detect the end of the program by seeing `0xFFFFFFFF` in `lr`, which is why code to ensure that it has that value was added in rust-embedded/cortex-m-rt#293. However, the `bl main` overwrites that value with the current program counter. This PR saves the old `lr` value on the stack, and adds debuginfo entries to allow an external unwinder to restore the value. This fixes knurling-rs/probe-run#277 Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
status: needs PR
Issue just needs a Pull Request implementing the changes
topic: unwinding
type: bug
Something isn't working
Describe the bug
I'm seeing a
(HOST) WARN call stack was corrupted; unwinding could not be completed
, even though unwinding seems to have worked fine and nothing happened that could have corrupted the stack.To Reproduce
Steps to reproduce the behavior:
cd testsuite; cargo test
Expected and observed behavior
Actual output:
Expected output: the same, but without the warning.
The text was updated successfully, but these errors were encountered: