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. Future work
  25. Related work
  26. Conclusions

Debugging as a service

Debugging as a Web service has many of the same advantages as other cloud services, including easy deployment, rapid updates, pervasive monitoring and telemetry, efficient use of resources across many clients.

Pernosco is resource-intensive and makes much more sense as a service than as packaged software running on non-shared hardware. Generating an omniscient database requires a lot of intensive processing, which is far more cost-effective to do with cloud spot instances than on intermittently-used, dedicated hardware. The databases are large, so keeping them in the same datacenter and serving query results to remote clients is much more efficient than moving the databases themselves. The implementations of Pernosco database queries are highly parallel, so the more cores the query server has, the lower the query latency and the better the user experience — but the overall utilization of the server by a single client is very low. Therefore the ideal configuration is to have a very large query server supporting a large number of simultaneous users.

We collect a lot of data about how people use Pernosco. We are mining our data to better understand how people debug, to guide improvements to Pernosco.

Implementing the debugger as a Web service makes it easy to implement collaboration features (e.g. a shared notebook). Collaborative debugging is important because for some bugs in complex systems, no single developer has the knowledge required to diagnose the bug. Collaboration features also facilitate non-debugging tasks such as showing another person how some code works. Collaboration features help spread the use of the tool. As far as we know, Pernosco is the first debugger to explicitly target collaboration.

A possible downside of debugging-as-a-service is that Pernosco requires access to test data and binary executables, which may be a problem for some potential customers. However, we believe in most cases this data is less sensitive than source code, and organizations are increasingly willing to entrust their source code to external hosting services. Pernosco does not require access to application source code; the Pernosco Web client can load source code from servers that the Pernosco service itself does not have access to. Of course some organizations will require an on-premises solution, which could be built for the right price.

As aspects of software development increasingly run as cloud services — e.g. code hosting, building, testing, deployment, and monitoring — it makes sense that debugging should also be integrated there. For example, Gitlab advertises itself as "the entire DevOps lifecycle in one application" but debugging is conspicuously missing.

<< Other workflows Basic interface >>