Destroying the evidence of a Crime Scene: Debugging the Codebase.

Jul 11 · 3 min read

Debugging is like a murdered hunting the crime scene for the evidence he/she has left. It is a discipline which develops critical and analytical thinking. This thought process can be applied to many aspects of life.

Here are few Debugging Rules

  • First, we need to identify the source of corruption and the corrupted entity.
  • Memory corruptions are usually because of illegal access or the race in the critical section.
  • Data corruption could be because of :
    1. External entity
    2. Software bug
    3. Hardware issue
    4. Lost write etc.

14. Look out for Performance Issues.
If you are very unlucky you might have hit on a Performance issue. Performance issues are very hard to reproduce and might occur intermittently.

  • For debugging performance issue we need to first identify the baseline test. This is a sample unit test which could be easily run and verify the slowness.
  • Eliminate the doubt of external factors, make sure the issue is not caused by some external factor.
  • In the case of comparison involved with other benchmark programs, make sure the comparison is done correctly.
  • Scan through each layer and see if there is anything going unexpected and causing delays.
  • Collect evidence at different layers/modules.
  • Try to Identify the module/layer having bottleneck or delays.
  • Once we identify the module/layer causing the delays, add time checks on entry and exit points to narrow down the exact problem.
  • Fixing is also a bit tricky with performance issues. Fix has to be thoroughly tested and checked against any regressions. “Performance fixes are really tricky and prone to cause regressions”.

15. There is always one more bug.
Finally, always assume there is at least one more bug. Never think, the bug you found is the final one.

Thanks for reading. Cheers!!! Feel free to leave your comments below.


Written by

Software Engineer @ WSO2, B.Sc.Computer Engineering