I am not sure what a monitored file descriptor is, but the following simple test program is crashing rr replay for me on 028e59b as well as on the fresh b5696b7 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
I am not sure what a monitored file descriptor is, but the following simple test program is crashing
rr replayfor me on 028e59b as well as on the fresh b5696b7 when running on Linux version 6.19.8+deb14-amd64 from Debian Sid.I tried invoking this as follows:
No matter if the redirections are present (if they weren’t, the system call would fail with
EINVAL),rr recordwould crash like this:If I launch the debugger, it will show just this:
If I disassemble the
mainin a separate invocation ofgdb /tmp/a.outit will be as follows: