handling of incomplete recordings for rr record and rr ls
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 52/100
Research direction
Start by locating the code paths for rr ls -l and rr record, then trace how incomplete recordings and early capability-check failures are handled. Run the relevant tests for listing and recording; done means an aborted recording no longer prevents a detailed listing, with the behavior for cleaning up or retaining failed recordings made clear.
Written by the indexing model from the issue text.
Description
rr ls gives me a listing of recordings. If I want to see a detailed list and enter rr ls -l, I get
rr: Trace file `/home/user/.local/share/rr/true-0/incomplete' found.
rr recording terminated abnormally and the trace is incomplete.
Any incomplete recording prevents a detailed listing from being printed
I presume these are aborted recordings because
> rr record true
rr: Saving execution to trace directory `/home/user/.local/share/rr/true-0'.
[FATAL src/PerfCounters.cc:407:start_counter()] rr needs /proc/sys/kernel/perf_event_paranoid <= 3, but it is 4.
creates the recording directory before doing the capability check.
The incomplete file contains the number "85" in ASCII and a newline, which doesn't seem like helpful information at first glance.
I think rr ls -l should list all traces by principle of least surprise.
I guess I would like rr record to not create a folder or have the ability to clean it up in the presence of an early failure.
Now that I know what to look for, I can obviously write a script to clean those recordings, but it would nice if casual users wouldn't have to worry about those details. Expert users using rr recordings in an automated fashion might want to keep a log of recording failures, but they are more likely to read the documentation and use the correct flags.
- Dominant language
- C++
- Stars
- 10.7k
- Forks
- 666
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 32
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing 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.
More from rr-debugger/rr
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
rr-debugger/rr#4145 ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 43/100
rr-debugger/rr#4127 · 1 comment ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
rr-debugger/rr#4060 · 5 comments ·
Maintainers usually reply within 2 days
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
rr-debugger/rr#4059 · 1 comment ·
Maintainers usually reply within 2 days
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
rr-debugger/rr#4047 · 4 comments ·
Maintainers usually reply within 2 days
Similar issues
-
Favicons are coolOpenenhancement frontend
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
-
Spot Capacity Round Trips tests accept the two largest rising runsPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
project: hipblaslt
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
ROCm/rocm-libraries#15746 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
bazel-contrib/rules_go#4784 · 1 comment ·
Maintainers usually reply within 1 day