in reply to debugging a race
I agree. This could be a red herring assumption. Start walking back through the commits in the version control system until you return to a point where the tests stop failing. Check-out that version to confirm that they have stopped. Now, compare the test scripts to make sure that they haven’t changed, and look over the tests that they perform to be sure that they still make sense in terms of the changes that have happened. Now examine the source-code changes. (This is one reason for the rune, “commit often.”)
The git version control system even provides a bug-chasing “binary search” to help you zero in on “the commit” that caused a particular malfunction to surface.
Unfortunately, debugging environments of various sorts are very often very different environments from the regular execution environment. Software often runs very, very differently ... which in my experience makes them not-so-useful except for microscopic troubleshooting.
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: debugging a race
by geoffleach (Scribe) on Nov 26, 2011 at 00:12 UTC |