In article ,
Dave Hinz wrote:
On Tue, 31 May 2005 22:35:31 -0000, Robert Bonomi
wrote:
Only to
find that *now* that the crime is happening "somewhere else". This was
a 'bug' with *legs* -- it MOVED!

Sounds like a timing problem (race condition)?

highly doubtful. *Absolutely* reliable for occuring and at what location in
any particular build.

It was just that inserting/changing the diagnostic instrumentation caused
the location to migrate.

Also, hard to get a timing problem, with a single, self-contained, module
that is merely doing a sh*tload of computations.

In desperation, played with the order in which the modules were linked,
found a sequence where (presumably *still* happening) memory corruption
did not affect the answers coming out, and released it that way. Put a
*LOUD* note in the source, documenting the existence of the problem; that
if the existing code was linked in _this_ order, the problem was 'harmless',
and that _any_ modification of any component was "highly risky".

I love finding those.

I figured that the next guy along deserved the information.
Heck, he makes some trivial one-line change, and the "Heisen-bug"
re-appears, and there he goes, trying to figure out how *THAT* change
causes the error "somewhere *totally* unrelated" to what he did.
Possibly even happens _before_ the program gets to the point where he
made the change.

This was documentation that *literally* started off:
"Warning, Will Robinson. WARNING!!"
and ended with "All hope abandon, ye who press 'enter' here."

My personal favorite is writing error messages like "There is no way
that you should ever see this error message." But, you don't want an
unhandled exception, even if it's "impossible".

I did enough of those, I had a standard format for it:
"Impossible error {{number}}
Internal program logic error.
Notify programming immediately!"