Breakpoints are skipped sometimes on lldb when the breakpoint is on line with error propagation '?' mark

[Nicceboy]

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.

 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.
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:

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:

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

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

[khuey]

I can't reproduce this on Linux fwiw.