madvise change (?) causes "rr" debugger to fail with 2.7.8 and 2.7.9

[arthurcnorman]

Windows Version

Microsoft Windows [Version 10.0.26200.8737]

WSL Version

0.0.0.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

Linux version 6.18.33.2-microsoft-standard-WSL2 (root@f1bbfb02316b) (gcc (GCC) 13.2.0, GNU ld (GNU Binutils) 2.41) #1 SMP PREEMPT_DYNAMIC Thu Jun 18 21:54:43 UTC 2026

Distro Version

Ubuntu 26.04 LTS

Other Software

rr version 5.9.0
(the record-replay debugger)

Repro Steps

hello.cpp:
#include
#include
#include <unistd.h>
int main()
{ std::cout << isatty(fileno(stdin)) << " hello\n";
return 0;
}
g++ -O0 -g hello.cpp -o hello
rr record ./hello

Expected Behavior

rr: Saving execution to trace directory ...

Actual Behavior

With 2.7.8 and 2.7.9 I observe the follwing, while before I went "wsl --update" thyings had been working as
expected and I have a valuable tool for debugging my code.

rr record ./hello
rr: Saving execution to trace directory /home/acn1/.local/share/rr/hello-7'. [FATAL ./src/record_syscall.cc:6733:rec_process_syscall_arch()] (task 1568 (rec:1568) at time 239) -> Assertion t->regs().syscall_result_signed() == -syscall_state.expect_errno' failed to hold. Expected EINVAL for 'ioctl' but got result 0 (errno SUCCESS); Unknown ioctl(0x802c542a): type:0x54 nr:0x2a dir:0x2 size:44 addr:0x7fff7b140950
Tail of trace dump:
{
real_time:2699.998405 global_time:219, event:SYSCALL: munmap' (state:ENTERING_SYSCALL) tid:1568, ticks:300566 rax:0xffffffffffffffda rbx:0x754190072b58 rcx:0xffffffffffffffff rdx:0x0 rsi:0xf035 rdi:0x754190009000 rbp:0x7fff7b1406f0 rsp:0x7fff7b1406e8 r8:0x880 r9:0x7fff7b1406c0 r10:0x7fff7b1406c0 r11:0x246 r12:0x7541900732e0 r13:0xfffffffffffffff8 r14:0x0 r15:0x7541900732e0 rip:0x75419005ea1b eflags:0x246 cs:0x33 ss:0x2b ds:0x0 es:0x0 fs:0x0 gs:0x0 orig_rax:0xb fs_base:0x75418feab780 gs_base:0x0 } { real_time:2699.998471 global_time:220, event:SYSCALL: munmap' (state:EXITING_SYSCALL) tid:1568, ticks:300566
rax:0x0 rbx:0x754190072b58 rcx:0xffffffffffffffff rdx:0x0 rsi:0xf035 rdi:0x754190009000 rbp:0x7fff7b1406f0 rsp:0x7fff7b1406e8 r8:0x880 r9:0x7fff7b1406c0 r10:0x7fff7b1406c0 r11:0x246 r12:0x7541900732e0 r13:0xfffffffffffffff8 r14:0x0 r15:0x7541900732e0 rip:0x75419005ea1b eflags:0x246 cs:0x33 ss:0x2b ds:0x0 es:0x0 fs:0x0 gs:0x0 orig_rax:0xb fs_base:0x75418feab780 gs_base:0x0
}
{
etc etc.

Diagnostic Logs

No response

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.