Bug 2459980
| Summary: | rr 5.9.0 aborts on Linux 6.13+ kernels with unknown madvise(102) - upstream fix already in master, please refresh package | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | maherr <bugzilla> |
| Component: | rr | Assignee: | William Cohen <wcohen> |
| Status: | ON_QA --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 43 | CC: | amerey, suraj.ghimire7, wcohen |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
FEDORA-2026-3afe7f2c47 (rr-5.9.0-9.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-3afe7f2c47 FEDORA-2026-5cd6e64d53 (rr-5.9.0-9.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-5cd6e64d53 Thank you for the detailed bug report. Backporting the upstream commit to fix this issue is in progress. FEDORA-2026-3afe7f2c47 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-3afe7f2c47` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-3afe7f2c47 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2026-5cd6e64d53 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-5cd6e64d53` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-5cd6e64d53 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2026-3afe7f2c47 (rr-5.9.0-9.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2026-5cd6e64d53 (rr-5.9.0-9.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report. |
rr 5.9.0 (the version in Fedora 43) aborts when recording any multi-threaded program on Linux 6.13+. The kernel added MADV_GUARD_INSTALL (advice value 102) and MADV_GUARD_REMOVE (103) in Linux 6.13, and modern glibc uses them for thread-stack guard installation. rr 5.9.0 doesn't know these advice values and trips a fatal assertion in its syscall recorder. Impact: blocks all Fedora 43 users with kernel >= 6.13 from using rr on any threaded program, which is most real-world workloads (Python with threads, Rust async runtimes, anything using glibc pthread stack guards). The fix is already merged upstream. rr master at commit 95b6860 (2026-04-21) has the handler at src/record_syscall.cc:5329-5332 emulating MADV_GUARD_INSTALL and MADV_GUARD_REMOVE as returning -EINVAL. Building rr from current master resolves the issue completely, verified on this box. Request: either pull a snapshot build past commit 95b6860, or rebase on the next upstream release whenever it ships. Upstream has been quiet on the release front (5.9.0 was tagged 2025-02-13, nothing since), so a snapshot build may be the pragmatic move. Reproducible: Always Steps to Reproduce: 1. rr record python3 -c "import threading, time; t = threading.Thread(target=lambda: time.sleep(0.01)); t.start(); t.join()" Actual Results: [FATAL src/record_syscall.cc:6754:rec_process_syscall_arch()] Assertion `t->regs().syscall_result_signed() == -syscall_state.expect_errno' failed to hold. Expected EINVAL for 'madvise' but got result 0 (errno SUCCESS); unknown madvise(102) rr then aborts and produces an emergency debug prompt. No trace is recorded. Expected Results: rr records the program successfully and produces a replayable trace. Additional Information: Version info: - rr-5.9.0-4.fc43.x86_64 - kernel 6.19.11-200.fc43.x86_64 - glibc-2.42-10.fc43.x86_64 Upstream rr master (commit 95b6860 as of 2026-04-21) has the fix at src/record_syscall.cc:5329-5332: case MADV_GUARD_INSTALL: case MADV_GUARD_REMOVE: syscall_state.emulate_result(-EINVAL); break; This emulates both advice values as returning -EINVAL at the rr layer, matching pre-6.13 kernel behavior. rr's deterministic replay doesn't need real guard-page installation, so no user-visible functionality is lost. Verified a master build (cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -Ddisable32bit=ON .. && ninja) records and replays the previously-failing command. Happy to help test a package update once a new build is available.