Assertion `current_syscall == expect_syscallno || current_syscall == expect_syscallno2' failed to hold. Should be at execve, but instead at clone

I'm running into this frequently. Current reproduction steps: start a replay. Continue until it hits the end. (There's no crash or anything.) Set a breakpoint at an address. Reverse-continue.

(rr) b *0x7f44d7afa0d4
Breakpoint 1 at 0x7f44d7afa0d4: file tree.c, line 2032.
(rr) rc
Continuing.
[FATAL /home/sfink/src/rr/src/replay_syscall.cc:125:__ptrace_cont()]
(task 15769 (rec:15338) at time 610)
-> Assertion `current_syscall == expect_syscallno || current_syscall == expect_syscallno2' failed to hold. Should be at execve, but instead at clone

It doesn't require setting the breakpoint on a magic address; I'm using that because it's the simplest way to reproduce. In actuality, I'm setting a breakpoint on a particular line in the file tree.c, only there are two tree.c files and it'll pick the wrong one. Especially since when the replay starts, the one I wanted hasn't been loaded into memory yet (it's in a gcc plugin). So what I'm really doing is starting the replay, setting a breakpoint on sixgill/gcc/tree.c:2032, gdb says it's pending, then continuing, discovering it hits too much and disabling, continuing to the end, enabling, reverse-continuing. It then crashes in the same way.

If I only run forward (eg by setting the breakpoint, but making it continue immediately so I don't have to manually continue 48 times), it does not crash.

This was with an older version of rr, but I rebased on top of aa238112cc6 and it's still happening. (I'm running with https://github.com/mozilla/rr/pull/2262 rebased on top.)

Read src/replay_syscall.cc at __ptrace_cont(), then reproduce the failure by setting a pending breakpoint in sixgill/gcc/tree.c:2032, continuing to the end, and reverse-continuing. Compare the expected execve syscall with the observed clone syscall. Done means this workflow no longer triggers the assertion.