It’s a riff on Heisenberg’s uncertainty principle — a bug that changes behaviour when you try to observe it, typically the sort of bug that you can’t reproduce under debug conditions. Often they’re race conditions or other timing-sensitive bugs, and the debugger changes timings enough that the bug doesn’t trigger.
I fondly remember a bug that only appeared when print statements were removed. The i/o of the system out was just long enough for some buffer to clear, making the app work. That was very annoying.
half a year old at least, as long as the first file is a readme it will open that one instead of the actually clicked file in a new window no matter what. Only fix is to remove the file
but if Xcode is instead set to open as new tab instead of new window, instead everything works just fine.
> It’s a riff on Heisenberg’s uncertainty principle — a bug that changes behaviour when you try to observe it...
As an aside, the Heisenbug is erroneously named because the phenomenon being described is actually the observer effect ( https://en.wikipedia.org/wiki/Observer_effect_(physics) ). The uncertainty principle refers to something entirely different.
A bug that this one customer keeps reporting and no developer in the team can replicate, until it happens one day and it happens constantly, until you try to debug it, because then the bug will never happen again. ️
To me, it's a bug which disappears when a debugger is attached... by observing it you're modifying the behaviour. I see the other comment here, I'd not heard of that explanation..
It doesn't have to involve a debugger. I had a sporadic bug once that couldn't be reproduced, which turned out to only appear when one performed an action quickly. When debugging, one tends to perform the steps to reproduce carefully, and hence slowly...
