
Heisenbug - crisp
https://en.wikipedia.org/wiki/Heisenbug
======
madethemcry
One of the first heisenbugs I encountered was IE8's console.log.

That object/function was only defined when the developer tools were open.
Otherwise you would get an exception (but of course you couldn't see that
exception in any place).

Daily effect was funny: When you forgot a console.log in your code your page
JS would hang. When you tried to debug it by opening the developer tools
everything worked- and you started to doubt your sanity pretty soon.

I wasted hours of my life with that.

~~~
neotek
But... how on earth did that escape QA? I mean surely even whoever was
developing IE8's developer tools would have had accidentally forgotten a
console.log() or two during development, surely?

~~~
dpwm
You have to be mindful of the fact that IE8 was the first IE to have
console.log[0] and that as a result it is possible that it wasn't used by the
developers. It's also possible they always had the console open during
development.

How did this ever manifest itself? The only thing that seems a plausible
explanation is that the console injects the console object or the console.log
function into the global JavaScript scope when it is opened and according to
the behaviour described and either garbage collected or removed from scope
when the console was closed. This seems like it could have only really been
the intended behaviour.

[0] [https://developer.mozilla.org/en-
US/docs/Web/API/Console/log...](https://developer.mozilla.org/en-
US/docs/Web/API/Console/log#Browser_compatibility)

------
d33
Obligatory:
[https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161](https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161)

I wonder if at one point we'll end up with a crisis that will make us see
excessive complexity as a bug on its own.

~~~
slx26
Probably 'bug' is not the best word, but many programmers definitely consider
excessive complexity as 'bad design' (unless complexity is inherently
unavoidable due to the very nature of the problem).

~~~
digi_owl
And others pile it on in the name of "user friendliness" or "security"...

~~~
majewsky
User friendliness and security are not the parts that are bad. "Piling them
on" is the part that's bad. UX and security need to be considered from day
one.

------
michaelmcmillan
Reminds me of the "can't send mail more than 500 miles" bug. Fantastic read:
[http://web.mit.edu/jemorris/humor/500-miles](http://web.mit.edu/jemorris/humor/500-miles)

------
EliRivers
These (and bugs of other types) can make fantastic war stories for interviews.
I have a few such stories from my own experience that I am practiced in
telling; they're a really good opportunity to showcase your technical chops in
puzzling situations, and also show that you're a personable character able to
communicate effectively on technical issues, _and_ an opportunity to
demonstrate real enthusiasm and engagement.

The hook "Tell me about an interesting bug you had to fix" or similar is
absolute gold; if you've got a good one lined up, you can dazzle with your
diagnostic procedure and explain what you tried and thought of and discounted,
showing a wide range of technical expertise and more general investigative
procedure. Tell it well and lead them through it, and they will start coming
up with ideas and suggestions, making themselves part of the discussion.
Ideally, they'll even tell you about something similar they once had to deal
with. By the end of the five minute story-telling, you're more than just
interviewer-interviewee.

I plan ahead for these; I have three interesting (well, as interesting as
these things get) crazy bug stories ready to go, delivery practiced, and I'll
pick one based on other factors of the interview. They're also good for non-
interviews; meeting someone at a conference or when working with another
company - it's an interesting conversation that the other person can feel
involved in and enjoy listening to, and by the end of it you're in their mind
as a competent person, good at the job, who is also engaging and communicative
and fun to chat to. Because it's true! If you've got interesting material, and
you can deliver it well and engagingly, you _are_ all those things. It's not
even a trick!

If you don't plan ahead, you're planning to fail (is the kind of aphorism that
makes me want to punch someone but I grudgingly accept is true).

------
lordnacho
Every coder at some stage has run into this, right?

\- A bug that disappears when you try to add some cout<< lines.

\- Everything looks correct in debug, where (as mentioned) the variables are
initialised to nice values like 0. When you compile with -O3, you get really
large values instead.

\- A bug that is rare enough that you have to run the program for a long while
before it happens. And when it does, you haven't logged the relevant
information.

\- A bug that only manifests when you're not trying to show a colleague.

~~~
dbcurtis
> Everything looks correct in debug, where (as mentioned) the variables are
> initialised to nice values like 0. When you compile with -O3, you get really
> large values instead.

Uninitialized variable. Turn on warnings.

------
DandyDev
Obligatory link to this classic blog post explaining heisenbug and many other
classic programming puns: [http://www.dodgycoder.net/2011/11/yoda-conditions-
pokemon-ex...](http://www.dodgycoder.net/2011/11/yoda-conditions-pokemon-
exception.html?m=1)

------
jpatokal
My little contribution to the genre's literature:
[https://gyrovague.com/2015/07/29/crashes-only-on-
wednesdays/](https://gyrovague.com/2015/07/29/crashes-only-on-wednesdays/)

------
gardarh
Reminds me of the time I decided to always start using braces for if
statements. I was figuring out why this line didn't work:

    
    
      if(condition)
         doSomething()
    

And naturally the obvious thing do to was to add a debugging statement:

    
    
      if(condition)
        logSomething()
        doSomething()
    

And if I remember correctly all of a sudden the bug didn't exist anymore for
the condition I was reviewing. Took me a while to figure out what was going
on. Lesson learned: Just always use braces.

~~~
jug
A variant of that one led to quite a security bug for Apple:
[https://blog.codecentric.de/en/2014/02/curly-
braces/](https://blog.codecentric.de/en/2014/02/curly-braces/)

------
dmoreno
I loved the heisenbug/bohrbug distinction in the zen of Erlang [1]:

> Basically, a bohrbug is a bug that is solid, observable, and easily
> repeatable. They tend to be fairly simple to reason about. Heisenbugs by
> contrast, have unreliable behaviour that manifests itself under certain
> conditions...

It continues talking that for some kind of heisenbugs, one smart strategy is
just to restart to a known state, and forget about this one in a million
failures (let it crash).

[1] [https://ferd.ca/the-zen-of-erlang.html](https://ferd.ca/the-zen-of-
erlang.html)

------
mercer
Reminds me of "The Zen Of Erlang": [https://ferd.ca/the-zen-of-
erlang.html](https://ferd.ca/the-zen-of-erlang.html)

------
bookofjoe
Software equivalent of pain that brings you to a doctor's office that
disappears upon medical examination.

------
blaze33
Reminds me of the people who couldn't send email farther than 500 miles.

[https://www.ibiblio.org/harris/500milemail.html](https://www.ibiblio.org/harris/500milemail.html)

~~~
drharby
Warms my heart that ttl was the first thing i thought of when hearing the bug.

------
dboreham
I transitioned over from hardware design long ago. We had a similar concept
where the circuit would work, but only when an oscilloscope probe is attached
at the right place..

~~~
spearo77
like this? [https://www.eevblog.com/2018/02/15/eevblog-1057-µcurrent-
mur...](https://www.eevblog.com/2018/02/15/eevblog-1057-µcurrent-murphy/)

~~~
dboreham
I was going to say, like in this :
[https://xkcd.com/730/](https://xkcd.com/730/)

Except even after 10 minutes staring at his circuit diagram, I can't see the
"attach scope probe here" so I must have dreamed it.

Back in the day we would muse about selling a "scope probe emulator" device
that had the same 10pf capacitance or so, but was much smaller than an actual
oscilloscope and could therefore easily be incorporated into a production
board. Of course now oscilloscopes are sufficiently small and cheap that you
could simply use a real one.

------
knocte
If you hate heisenbugs, use Functional Programming (or data-race-safe langs
such as Rust). It will kill 99.99% of them.

~~~
majewsky
That's assuming that heisenbugs are caused by concurrent programming alone.
But a ton of heisenbugs happen in boring single-threaded programs.

~~~
knocte
Tons? In my entire career I haven't found one of those.

~~~
mikerg87
Any programming language with pointers such as C or c++ where you can have
wild pointers, use after free etc can be a breeding ground or hisenbugs.
Consider yourself lucky.

