Assertion copy_file_range for monitored fds not supported yet

I am not sure what a monitored file descriptor is, but the following simple test program is crashing rr replay for me on 028e59b7cd2b7ab88677960b7dbd72baf347593f as well as on the fresh b5696b76b706d347ddb99eb7ab99bd8e7b8f13c2 when running on Linux version 6.19.8+deb14-amd64 from Debian Sid.

#define _GNU_SOURCE
#include <unistd.h>
int main()
{
  return (int) copy_file_range(STDIN_FILENO, NULL, STDOUT_FILENO, NULL, 1U<<31, 0);
}

I tried invoking this as follows:

touch /tmp/a
_RR_TRACE_DIR=/dev/shm/rr rr record ./a.out < /tmp/a > /tmp/b

No matter if the redirections are present (if they weren’t, the system call would fail with EINVAL), rr record would crash like this:

[FATAL src/record_syscall.cc:4546:rec_prepare_syscall_arch()] 
 (task 75012 (rec:75012) at time 165)
 -> Assertion `!t->fd_table()->is_monitoring(in_fd) && !t->fd_table()->is_monitoring(out_fd)' failed to hold. copy_file_range for monitored fds not supported yet
…
=== Start rr backtrace:
rr(_ZN2rr13dump_rr_stackERNS_8ScopedFdE+0x4d) [0x5570213821e2]
rr(_ZN2rr15emergency_debugEPNS_4TaskE+0x113) [0x5570211a2a61]
rr(+0x3da509) [0x5570211a6509]
rr(_ZN2rr21EmergencyDebugOstreamD1Ev+0x5f) [0x5570211a675d]
rr(+0x468849) [0x557021234849]
rr(+0x451c1d) [0x55702121dc1d]
rr(+0x47441e) [0x55702124041e]
rr(+0x451ce6) [0x55702121dce6]
rr(_ZN2rr19rec_prepare_syscallEPNS_10RecordTaskE+0x74) [0x55702121dd64]
rr(_ZN2rr13RecordSession21syscall_state_changedEPNS_10RecordTaskEPNS0_9StepStateE+0x39c) [0x557021200e22]
rr(_ZN2rr13RecordSession11record_stepEv+0x594) [0x557021207e96]
rr(+0x42e531) [0x5570211fa531]
rr(_ZN2rr13RecordCommand3runERSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE+0x498) [0x5570211fb4ae]
rr(main+0x287) [0x5570211b8736]
/usr/lib/x86_64-linux-gnu/libc.so.6(+0x29f75) [0x7f3f4590ff75]
/usr/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x87) [0x7f3f45910027]
rr(_start+0x21) [0x5570210994c1]
=== End rr backtrace
Launch debugger with
  'gdb' '-l' '10000' '-ex' 'set sysroot /' '-ex' 'target extended-remote 127.0.0.1:42940' '/tmp/a.out' 

If I launch the debugger, it will show just this:

0x00007f8520681e92 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) bt
#0  0x00007f8520681e92 in _start () from /lib64/ld-linux-x86-64.so.2
#1  0x0000000000000000 in ?? ()
(gdb) disassemble
Dump of assembler code for function _start:
=> 0x00007f8520681e92 <+0>:	add    $0x18,%rsp
   0x00007f8520681e96 <+4>:	ret
   0x00007f8520681e97 <+5>:	nopw   0x0(%rax,%rax,1)
End of assembler dump.
(gdb) disassemble main
Dump of assembler code for function main:
   0x0000000000001139 <+0>:	
❌️ Cannot access memory at address 0x1139

If I disassemble the main in a separate invocation of gdb /tmp/a.out it will be as follows:

   0x0000000000001139 <+0>:	push   %rbp
   0x000000000000113a <+1>:	mov    %rsp,%rbp
   0x000000000000113d <+4>:	mov    $0x0,%r9d
   0x0000000000001143 <+10>:	mov    $0x80000000,%r8d
   0x0000000000001149 <+16>:	mov    $0x0,%ecx
   0x000000000000114e <+21>:	mov    $0x1,%edx
   0x0000000000001153 <+26>:	mov    $0x0,%esi
   0x0000000000001158 <+31>:	mov    $0x0,%edi
   0x000000000000115d <+36>:	call   0x1030 <copy_file_range@plt>
   0x0000000000001162 <+41>:	pop    %rbp
   0x0000000000001163 <+42>:	ret

The assertion is in src/record_syscall.cc at rec_prepare_syscall_arch(); start there and trace how copy_file_range handles monitored input and output descriptors. Re-run the supplied C reproducer under rr record with the /tmp redirections, then confirm it no longer aborts on the assertion and can replay the trace.