A bug that disappears or alters its behavior when one attempts to probe or isolate it. (This usage is not even particularly fanciful; the use of a debugger sometimes alters a program's operating environment significantly enough that buggy code, such as that which relies on the values of uninitialized memory, behaves quite differently.)
Could be the reason of bugs reported that cannot be reproduced?
Yes, this can be part of it, particularly when it involves race conditions or corruption. The methods to look for the problem cause it to temporarily disappear.
A good number of our "bugs" are actually due to missing features. So other ways to get whatever functionality are used. Then when things are added and things are modified to be more Windows compliant, then there are breakages where we temporarily did it our own way due to a lack of proper underlying APIs. From analyzing the commits, I believe this has happened lately. As certain security-related functions were fixed, some of the hack fixes had to be rewritten, and others functions were simply redirected to use the appropriate APIs which now exist.
To the poster above me, I think the article says the opposite, that it is a bug that exists until you look for the cause. I hated that in electronics where it would always malfunction until you started working on it, and any "shotgun" actions like randomly reheating solder junctions seem to help. And you might tap on it, blast it with compressed air, etc., and the malfunction doesn't occur until you put the cabinet back together. So in this case, adding a few lines to get output where the wrong values should be manages to change the program enough to hide the problem. If you are having a race condition, then adding screen or logging output right in the middle of where it occurs may serialize the operations and cause the dependant condition to wait on the prerequisite condition where it doesn't.
I have to say I find object orientated programming is meant to make programming so much easier and more elegant - and of course it does. One of its strengths is meant to be a reduction in buggy code. However, I always find the really, really difficult bugs - the ones that seem to act in contradiction to your logic, the Heisenbug ones, are often related to OO programming, the use and re-use of objects programmed and documented by someone else. Unpredictable behaviour seems to be the most difficult to track down, be it timing, incorrect variable references, pipes, mailboxes, failing to free memory, they all seem to be within the OO side of things. Sometime I yearn for a return to functional methods, I think I should return to Quick BASIC, I was happy there...
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
