1. Overview
  2. Debugging and CI
  3. Other workflows
  4. Debugging as a service
  5. Basic interface
  6. Call stacks
  7. Explaining dataflow
  8. Multiprocess
  9. Search box
  10. Source files
  11. Condition and print expressions
  12. Toolbox
  13. Alerts
  14. Application logs
  15. Callees
  16. View operators
  17. Notebook
  18. Instruction execution
  19. Browser UI integration
  20. Additional views
  21. GDB
  22. System debug info
  23. Compiler issues
  24. Related work

Other workflows

CI integration alone does not let Pernosco support all the debugging developers do. We have built additional tools to integrate Pernosco into developers' workflows.

Developer uploads

We have a tool that lets users submit rr recordings to Pernosco for debugging. Developers can record a bug locally, submit to Pernosco, wait half an hour (for example), and receive an email with a link to the debugging session. The extra latency over immmediate local debugging with rr is unfortunate, and we can reduce it, but we think that one-off latency is worth trading off for reduced latency of every user interaction during the actual debugging session.

QA workflows

Many workflows involve developers pulling work from a bug tracker. Actionable bug reports typically contain steps to reproduce the bug; in that case, manual or automated systems could record the buggy execution, process it with Pernosco and link to the Pernosco debugging session from the bug report. We did this manually for a number of Mozilla Firefox bugs (e.g. bug 1490117). Some projects have infrastructure that can file bugs with testcases automatically (e.g. via fuzzing); that infrastructure could automatically generate Pernosco debugging sessions for those bugs.

Production systems

Better record-and-replay systems could overcome rr's limitations and make it feasible to record the execution of applications in production, both for services and client applications. For this to be feasible for most workloads, new approaches will need to be implemented in software (e.g. extending the Linux kernel itself) or possibly hardware. We have some ideas on how this could work but it requires significant investment.

<< Debugging and CI Debugging as a service >>