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
    Thanks for the two replies.

    My assumption that there was a race somewhere was based on the fact that the problem went away when I ran the test under profiling.

    Otherwise, I have a baseline on which the test I quoted runs correctly. I'm n the process of walking back module changes, but its painful, because failures are not consistent. By that I mean that the test will pass, and then somewhat later, under what appear to be the same conditions, will fail.