Seitenanfang

Hunting a Padre bug

Dieser Post wurde aus meiner alten WordPress-Installation importiert. Sollte es Darstellungsprobleme, falsche Links oder fehlende Bilder geben, bitte einfach hier einen Kommentar hinterlassen. Danke.


Padre is not only "some open source project I'm involved", but a tool I'm using for every day's work. Yesterdays "svn update" brought a new bug, files as ticket #1286. Hunting down a newline issue isn't that easy, because many things from Wx events, encoding, line ending up to keypress-events or intelligent code suggestion may have the bug.

More than 200 commits came in between the last known-to-be-working and the known-to-be-broken svn revision, so surfing through the changelogs would be a really long term jobs.

Here is what I know:

  • revision 15346 is broken
  • some revision around 15115 was working
At first, I got to verify these values, so "svn update -r 15100" took me back in time to a revision some days ago. Running Padre, creating a new document and pressing "ENTER" (RETURN) made one newline - everything ok here.

I didn't try out the bug on a blank file before, so maybe it was there in 15100 but it doesn't happen in new files? Updating to revision 15300 and testing again verified two things:

  • The bug is reproduceable with a new, blank file and one ENTER touch
  • The bug was already here in 15300
Now it's clear that this small unwanted insect crawled in between 15100 and 15300. Testing each revision would be very time consuming, so I'll try to catch it with less than 10 tests:
  1. revision 15200 is working, bug must be between 15200 and 15300
  2. cut down the remaining options by half: revision 15250 is working
  3. revision 15275 (again the middle between known-working and known-broken) working, too
  4. revision 15287 working
  5. revision 15294 is broken, but due to source syntax typos in Padre/Config.pm, no answer about the bug
  6. revision 15295 fixes the typos, but has the bug I'm hunting, it was introduced between 15287 and 15294
  7. revision 15290 is bug-free, four revisions and three tests left
  8. revision 15292 is working
  9. revision 15293 updated the translation database only, no chance this could be the bug source
I suspect 15294 to introduce the bug, but it has typos in the source and is untestable. It changed three files, Editor.pm, Main.pm and Config.pm. Both Editor.pm and Main.pm are good places for the bug to hide, Config.pm is very unlikely and has the typos.

To verify the assumption, current trunk (15349) plus Editor.pm and Main.pm from 15293 will go for the next test. This may also crash Padre because two main source files are much older than the rest of the source, but it worked and didn't have the bug. Using both files from 15394 showed the bug. The commit to Padre trunk revision 15394 made huge changes to the Editor and smaller changes to Main.pm. Life would be easy if Main.pm would be the source, but I didn't expect the changes shown in trac to be responsible and unlikely I was right.

Now, running current trunk with old 15394 Editor.pm, intelligent use of a versioning system took me as near to the evil little bug as it could, reducing some 1000 lines of changed source down to 100 or so, I'll step down into the commit checking the lines and trying around until #1286 is fixed, but this may be the story of another blog post...

 

4 Kommentare. Schreib was dazu

  1. You've just described git bisect :)

  2. Sebastian

    Wow, I didn't expect something that easy to have tools. :-)

  3. Jakub Narebski

    It is not as easy if history is non-linear (branchy). And there is also 'git bisect run' for automated testing and 'git bisect skip' for marking those revisions that are untestable.

  4. Nitin Garg

    Nice use of the binary search concept! :D

Schreib was dazu

Die folgenden HTML-Tags sind erlaubt:<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>