A Short Story of a Firefox Bug
This is what it looks like when bug fixes work as intended.
2009-05-17T20:47:35Z PEG: debugging (mostly stuff that used to work, possibly a change in Mozilla trunk?)
Sunday, early afternoon: I am working through the weekend, getting a parser generator I'm writing finished.
It's almost working, just a few bugs left.
I've had a Minefield build running for a few weeks, and it's getting a bit stale, so I quit it and restart with a more recent build.
Immediately, about five tests change from green to red, in code I haven't touched in weeks.
Naturally, I assume this is my fault and spend a couple hours debugging, but against all odds it seems to be a browser bug.
2009-05-17T21:47:46Z PEG: debugging
After a break, I come back for another hour of further narrowing down the problem.
I add some logging calls to the function, and immediately it behaves correctly.
The log() function uses some regexes, and regex literals are connected to the problem; I spend some time chasing this down but it turns out to be unrelated.
Logging shouldn't change the behavior, but it's still possible for this to be a bug in my code, so I reduce the number of things I log, eventually to zero, so I just have an empty log() call.
Even with just that, the function works as expected, but when I comment out the log() call, it breaks.
In fact the function works when I replace "log();" with "log;", so I'm not even calling the function now, just referencing it (and throwing away the reference).
I replace "log;" with "window;", and the function still works, but with "window;" commented out, it breaks.
It's now clear that this is a Firefox bug, as a "window;" statement should always be a no-op, so I start to collect all the code necessary to demonstrate it into a separate file.
I could keep working and submit a bug report, but I decide to go for a hike instead.
2009-05-18T20:36:24Z PEG: writing a test case for the Firefox bug I found
Monday afternoon: I create a minimal test case in a single file.
Extracting and collecting all the code from several files, editing it so that it (a) runs, and (b) exercises the bug takes over three hours, and makes me think about automation.
Finally the test case is ready and comprehensible.
2009-05-18T21:14:42Z submitting Firefox bug 493625
I ask the helpful folks in the Firefox IRC channel for help reporting a bug.
I find my way around Bugzilla, fill out a form, make some last tweaks to the test case, and submit a bug.
Bugzilla assigns it number 493625.
The whole thing takes about 40 minutes.
I get some email telling me that the bug was created.
I stare at the screen for awhile and refresh the bugzilla page a couple times, but nothing happens.
I decide to go out for some food instead.
2009-05-18T17:20:58Z watching my bug's progress
Later Monday evening, I check the bug report, and my email.
At 17:23:30 PDT, David Mandelin finds the patch that introduced the problem, "a 1-line patch to jsparse.cpp".
Thirty-four minutes later, the bug is marked as a duplicate of an earlier bug, 493466.
2009-05-18 18:03:21 PDT
I clone the hg tracemonkey branch so I can test it myself, and start a build.
2009-05-19T15:54:28Z sudo make -f client.mk install
Tuesday morning: my build has finished some time previously, so I install it.
Minefield is still running, so I won't know if the problem is fixed until later, when it's convenient for me to restart the browser and test it.
2009-05-19T20:17:21Z PEG: testing the Firefox bug fix
Tuesday afternoon: I quit Minefield and restart with the tracemonkey build from yesterday's source code, including Brendan's fix.
I clean up my tests, undoing some of the things I changed while trying to debug the problem, and my tests are green again.
I blog about it, and go back to hunting for bugs of my own.