Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A Practical Taxonomy of Bugs and How to Squash Them-SunshinePHP

Kylie
February 03, 2017

A Practical Taxonomy of Bugs and How to Squash Them-SunshinePHP

Review my talk and give me feedback: https://joind.in/talk/3f670
Catching software bugs is a mysterious magic, unknowable by science and untouchable by process.

False! Programming bugs, like real bugs, can be organized into a taxonomy. Come with me and I'll show you how classification can help you build “programmer’s instinct” into a logical debugging process.

Debugging may be instinctual but those instincts come from seeing, identifying and diagnosing patterns. In this talk, we’ll use phenetic taxonomy to build a debugging decision making network based on attributes and behaviors of common bugs. Newer developers will learn how to apply systematic pattern matching to debugging while seasoned developers will learn how to use their instincts to teach debugging.

Kylie

February 03, 2017
Tweet

More Decks by Kylie

Other Decks in Programming

Transcript

  1. “Whenever I see something like this happening, the first thing

    I do is scan the logs to see if this process is completing or is sending a weird message.”
  2. Research Methods • containment sometimes takes priority over squashing •

    we can only work with facts • we can’t squash every bug in this talk
  3. Observable Attributes is the bug observable in production? can it

    be reproduced locally? does it seem to be restricted to one area?
  4. Reproduction & Resolution replicate locally and in test write the

    simple solution rewrite to be highly readable and extendable UPSETTINGLY OBSERVABLE
  5. Observable Attributes how does this work? does this work? wait,

    what is this even testing? did this ever work?
  6. Schrödinbug Likes to pretend to be working code. On close

    inspection, reveals itself to be a bug. UPSETTINGLY OBSERVABLE
  7. Schrödinbug Type I. In the wild: UI shows update but

    database entry not updated. UPSETTINGLY OBSERVABLE
  8. Basic Reproduction & Resolution replicate locally and in test write

    the simple solution rewrite to be highly readable and extendable UPSETTINGLY OBSERVABLE
  9. Reproduction & Resolution reproduce the “broken” state locally and in

    test add log statements until you can verify what causes the broken state.
  10. Reproduction & Resolution reproduce the “broken” state locally and in

    test add log statements until you can verify what causes the broken state. if the bug did work at some point, find the point at which it did work.
  11. Reproduction & Resolution reproduce the “broken” state locally and in

    test add log statements until you can verify what causes the broken state. if the bug did work at some point, find the point at which it did work. write tests to represent the configuration and flow of the fixed state
  12. Reproduction & Resolution use profiling to find the trigger state

    use the app (not fixtures or DB manipulation) to get the data in this state
  13. Reproduction & Resolution use profiling to find the trigger state

    use the app (not fixtures or DB manipulation) to get the data in this state recreate that state in test
  14. Reproduction & Resolution use profiling to find the trigger state

    use the app (not fixtures or DB manipulation) to get the data in this state recreate that state in test follow borhbug instruction
  15. “The bug is huge and everywhere at once. SQL: could

    not connect to server: Connection refused was bubbling up all over the place. Jobs won’t run, emails won’t send, every submit button on the site fatal errored.” on-call log WILDLY CHAOTIC
  16. Reproduction & Resolution use df -h to find if all

    the storage is being use attempt to connect to server & view logs
  17. Reproduction & Resolution use df -h to find if all

    the storage is being used attempt to connect to server & view logs can that be restarted, rotated or killed at this time?
  18. Observe & Classify Verify with logging and time travel Verify

    without changing state by profiling Use server tools to observe entire process
  19. Resources & Further Study • “Linux Debugging Tools I Love”,

    Julia Evans • Systems Performance, Brendan Gregg • “Why Do Computers Stop and What Can Be Done About It?”, Jim Gray • “Debug Patterns for Efficient High- levelSystemC Debugging”, Frank Rogin, Erhard Fehlauer, Christian Haufe, Sebastian Ohnewald