Intermittent failure in `mutex_pi_stress`

Just saw this on Anubis:

[FATAL /data/keno/rr/src/RecordSession.cc:1506:process_syscall_entry() errno: SUCCESS]
 (task 50829 (rec:50829) at time 20260)
 -> Assertion `t->desched_rec() || is_rrcall_notify_syscall_hook_exit_syscall( t->regs().original_syscallno(), t->arch()) || t->ip() == t->vm() ->privileged_traced_syscall_ip() .increment_by_syscall_insn_length(t->arch())' failed to hold.
[FATAL /data/keno/rr/src/log.cc:289:emergency_debug() errno: SUCCESS] (session doesn't look interactive, aborting emergency debugging)

Seems like we also saw this on the KNL buildbot: https://ci.rr-project.org/#/builders/4/builds/93/steps/9/logs/stdio

[FATAL /home/rrbuildbot/rr-knl-baremetal/build/rr/src/RecordSession.cc:1508:process_syscall_entry() errno: SUCCESS]
 (task 228422 (rec:228422) at time 46702)
 -> Assertion `t->desched_rec() || is_rrcall_notify_syscall_hook_exit_syscall( t->regs().original_syscallno(), t->arch()) || t->ip() == t->vm() ->privileged_traced_syscall_ip() .increment_by_syscall_insn_length(t->arch())' failed to hold.
[FATAL /home/rrbuildbot/rr-knl-baremetal/build/rr/src/log.cc:289:emergency_debug() errno: SUCCESS] (session doesn't look interactive, aborting emergency debugging)

Start by reproducing the mutex_pi_stress failure and compare the Anubis and KNL buildbot traces. Inspect src/RecordSession.cc around process_syscall_entry() and the reported assertion. Done means identifying why the test reaches the assertion and adding a reliable regression check for the failure.