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.
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?
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.
This is one of my "favorite". I often remind junior developers who just started coding in the last few years about stuff like this since a lot of our client's still insist on IE8 support (thankfully not IE 6 or 7 anymore).
Another fun one was dangling commas in arrays, which breaks IE 7 and lower.
It used to be somewhat common to put something like this at the top of scripts:
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).
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.
Great bug. Disappointing that they all consider it a bug in `file` though, rather than an insane design where printing a document relies on parsing the output of `file`!! Madness.
Isn't it considered a bad practice already? But same as with regular bugs, complexity is not something one can just stop doing. It's something to actively manage and take care of.
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).
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.
> 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.
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.
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).
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..
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.
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.
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.
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...
Another fun one was dangling commas in arrays, which breaks IE 7 and lower.
It used to be somewhat common to put something like this at the top of scripts:
if ( window.console == undefined ) { window.console = { log: function() { }; }
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.
http://verticalsysadmin.com/blog/sysadmin-war-story-the-netw...
https://news.ycombinator.com/item?id=15258238
tldr; printers have a hardware cache for fonts that's cleared when rebooted, havoc ensues
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).
- 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.
Uninitialized variable. Turn on warnings.
> 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://www.ibiblio.org/harris/500milemail.html
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.