954: don't quit capturing a stacktrace when we encounter an invalid frame

[russelltg]

Fixes #954

Also add a test that covers this case

[russelltg]

Ha--thanks for the review. My solution was pretty incorrect b/c I had copied the startFrame from the previous test--obviously there are not 20 stack frames so that's why I thought the frame being invalid was the problem.

The problem was instead the the disassembly.from_address. I think this solution is actually proper, and now I understand what self.in_disassembly comes from

[timlathy]

Hi @vadimcn, is there a chance this could be merged and released soon? I have a problem with v1.9.2 where I get an "Internal debugger error: Can't read instructions at that address." message in the Call Stack window when debugging a Rust panic. Running a VSIX built from this PR seems to fix that: the frames for my code are shown correctly, though the top frames starting from core::panicking::panic are unavailable (I presume those are "invalid", but it doesn't really matter as long as I see my own code). If it helps, I'm using Rust 1.70 on Linux.

[russelltg]

Does bt in the debug console work?

[timlathy]

bt works, but it doesn't resolve source paths to my local source directory (.rustup/toolchains/.../lib/rustlib/src), instead it prints something like

frame #6: 0x00007ffff7f874dd libstd-8389830094602f5a.so`core::panicking::panic at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:117

So, with this PR applied, the debugger seems to behave as expected for my setup: it marks std/core frames as unavailable but displays the frames for my code and dependency crates correctly.

[sunho]

Any news on this PR? I'm working on JIT code generation where it's common for instruction pointer to point at weird place so this feature is very handy.

[vadimcn]

Sorry, didn't have time yet to deal with this. Looks like you've managed to get a local build with your changes, though, so you aren't blocked on this?

[vadimcn]

LGTM. Thanks!