rr-debugger / rr-debugger/rr

rr hits a fatal assert and prevents further replay

Open
#4,060 5 comments 0 reactions 0 assignees View on GitHub

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.