rr hits a fatal assert and prevents further replay
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 10.7k
- Forks
- 662
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 2
Description
First of all, thanks for this amazing tool.
Secondly, I'd like to debug and help understand the root cause of my issue, but I'm not very familiar with the internals, so I'll post an issue here in case I get some help.
When I replay a recording of my code, rr encounters a fatal error with the following message to stdout:
[FATAL src/Task.cc:1446:compute_trap_reasons()]
(task 23212 (rec:22828) at time 29708)
-> Assertion `as->is_breakpoint_instruction(this, ip_at_breakpoint)' failed to hold. expected breakpoint at 0x7f9455b9a421, got siginfo {signo:SIGTRAP,errno:SUCCESS,code:TRAP_BRKPT,addr:0x7f9455b9a422}
This happens only on the specific application I'm debugging and not in any simple hello world application.
Additionally, some replays go through and work well. This happens in around 90% of the replays.
Any help on how I can go about debugging it would be appreciated, since I cannot reveal details about the application I'm debugging.
Edit : I'm on Fedora 42 with rr version 5.9.
Thanks.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with src/Task.cc:1446 in compute_trap_reasons() and reproduce the failure using rr 5.9 on Fedora 42. Compare failing and successful replays around the reported time and breakpoint addresses, using the assertion output as the initial trace. Done means identifying a reproducible cause and documenting or fixing the failure, but the issue does not provide enough application detail to define a narrower test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, linux
- Domain
- devtools, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100