Repository: rust
Issue: Breakpoints are skipped sometimes on lldb when the breakpoint is on line with error propagation '?' mark
Labels: A-debuginfo,C-bug,WG-debugging

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I have this quite weird problem, when debugging with `rust-lldb`.
After figuring out why it happens, it might not be a big problem, but in this case it took a whole day.
Maybe it is not issue at all.

If I set a breakpoint into the function which has a line with error propagation '?' mark, e.g. 
```rust
 self.encode_non_negative_binary_integer(ranges[index + 1], &bytes)?;
```

All the breakpoints before that line will get skipped in that function, and debugger stops for that line.
If you look frame variables at this point, some will give error or invalid content which makes no sense, and changes on repetitive executions.

However, if you continue the debugger, it *then* goes the first breakpoint in that problematic function and stops correctly each of them. It stops again in that line where it was already, and this time the memory content is correct. 

**The problem does not occur, if I change `?` to the `.unwrap()` for example.**



This happens on CLion, VSCode CodeLLDB,  and `rust-lldb` command line on MacOS Sonoma aarch64.

The code is `#![no_std]`, and available [here](https://github.com/Nicceboy/rasn/blob/ae80efb56da29142c7888f4af742b9ce3eced43d/src/oer/enc.rs#L77). 
I tried to make smaller codebase to reproduce this, but unfortunately I was not successful. 

To reproduce, clone the branch, run `cargo build`.
A test must be executed from the linked file in `lldb`.

To be able to do that, also test target must be build.
Shellscript to build the target, and run the test in `lldb`:
```sh
TEST_EXECUTABLE="$(cargo t --no-run -q --lib --message-format=json  oer::enc::tests::test_encode_integer_manual_setup | jq -r '[inputs][-2].executable')"
rust-lldb "$TEST_EXECUTABLE"
```


To set breakpoints in command-line in order how they should be handled:
```
b src/oer/enc.rs:136
b src/oer/enc.rs:46
b src/oer/enc.rs:55
b src/oer/enc.rs:77
```
However, the actual order is `136 -> 77 -> 46 -> 55 -> 77`


To run the test:
```sh
run --test  oer::enc::tests::test_encode_integer_manual_setup --exact --show-output
```

In the branch there is `run_debugger.sh` which can be executed as `sh run_debugger.sh` which opens the debugger with built target, and inside the `lldb` run `command source lldb.commands` to get into the first breakpoint.

Change the marked line to use `unwrap` instead of `?` and the behavior changes.

### What should happen instead

I would expect that the debugger should not randomly jump over breakpoints. This does not usually happen when `?` propagation has been used and breakpoint is on that line. It also seems to read incorrect memory during the incorrect stop, or maybe it is some sort of shorthanded double execution... 

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

Happens in the latest `stable`, `beta` and `nightly`.

Stable

`rustc --version --verbose`:
```
rustc 1.71.0 (8ede3aae2 2023-07-12)
binary: rustc
commit-hash: 8ede3aae28fe6e4d52b38157d7bfe0d3bceef225
commit-date: 2023-07-12
host: aarch64-apple-darwin
release: 1.71.0
LLVM version: 16.0.5
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->