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

[hotsphink]

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

[hotsphink]

Here's a log of my replay session: rr-replay.log

And a pack file: https://gist.github.com/hotsphink/18cdcc3238a61f13a608edfac1052491/raw/23b458cc926d6dcc911fb5c9018ca90668ac0cd7/g++-9.tar.xz (at least until github complains to me about the size and I need to delete it.)

[hotsphink]

Oh, hm. I forgot to mention that this is in the 'cc1plus' process. And now I have found a much simpler reproduction:

% rr replay -p 15337
(rr) c
(rr) run
(rr) c

Though this time the assertion says

Should be at execve, but instead at prctl