2024- 2023
- 2022
- 2021
- 2020
- 2019
- 2018
- 2017
- 2016
2015
Tic Tac Toe- Hex Table
- Markov Chain
- Lobotomy Debugging
- Map Maker
- Programming Lessons
- Polyglot 13: Dart
- Noogler
- Trekker
- Live Coding
- Privilege Escalation
- Desk
- CS by Mail
- Blinkenlights
- Cuba
- Open Wifi
- SpaceX
- 2014
- 2013
- 2012
- 2011
- 2010
- 2009
- 2008
- 2007
- 2006
- 2005
- 2004
- 2003
- 2002
Lobotomy Debugging
1 November 2015
There are many strategies for debugging a mis-behaving program. Single-stepping through a debugger, unit tests, commit rollbacks, and (most commonly) using gut instinct. Normally after some head-scratching the problem becomes apparent. However, occasionally one runs into a bug that despite being 100% repeatable defies all the usual attempts to diagnose it.
I ran into such a bug in Blockly. If one performed a certain sequence of actions, Safari would crash. There was no obvious cause. Most debugging edits made the problem go away. It was clearly a WebKit bug, but in order to report it I needed a minimal test case. Blockly's 600 kb of code (plus the Closure library) does not qualify as a minimal test case. The only option was to painstakingly start with Blockly's codebase and delete lines one by one, testing each time to ensure the bug still existed. It took a day, but I eventually managed to reduce everything to 100 lines of code and file bug 149613. The resulting code is bizarre, it creates an unused image, deletes an empty CSS rule before reinserting it, and plays games with mouse events. But it consistently causes Safari to crash.
I call this "lobotomy debugging". It is guaranteed to reduce any bug to a minimal test case -- eventually. Now this bug is WebKit's problem.
