My definition of a heisenbug is slightly different. For me it is one that disappears when you try to observe it (for example by inserting printf's, logging code or running in the debugger or if it only occurs with particular build setting especially release build only).

Hard to reproduce reliably is a different but closely related category.

You're right. The bug described in the article is just of the "may fail under load / with multiple users / in real-life scenarios" variety.

In the zoology of bugs, that makes it a common Mandelbug (1), but not a rare Heisenbug (2). For an even more exotic species, see Schroedinbug (3).

(1) http://www.catb.org/jargon/html/M/mandelbug.html

(2) http://www.catb.org/jargon/html/H/heisenbug.html

(3) http://www.catb.org/jargon/html/S/schroedinbug.html

I think the proper term for the bug is "race condition", since it is triggered by timing

I first encountered this type of bug back in Z80 days. The fastest possible way to copy memory was using an unrolled sequence of POP/PUSH on the stack; however, if you forgot to disable interrupts while doing this, the data could be corrupted.

Your definition is correct. The term heisenbug has been around for quite a while, for example, it's in the Jargon File:

    http://catb.org/jargon/html/H/heisenbug.html

I have no idea where this guy got his nonstandard usage of the term from.

I totally agree. I've seen bugs that disappeared once I introduce some print statement. I heard a theory it had something to do with memory management. It's beyond my level of expertise to explain, but I have experienced a true Heisenbug.

Can be a timing issue or on rare occasions a compiler/interpreter bug either. There are probably other potential causes too.