What is heisenbag: history of the term and examples

    This is reference material about the Heisenbags. We are talking about how they look and how they relate to mainframes - the progenitors of the cloud.

    / photo Lars Zimmermann CC BY

    Heisenbug ( heisenbug or heisenbug) is a term describing errors that change properties during code debugging. That is, they disappear during testing and debugging, but appear in production.

    The name “Heisenbag” refers to the Heisenberg uncertainty principle of quantum mechanics. In general terms, it can be described as an unexpected change in the properties of the observed object as a result of the observation.


    The term Heisenbug is considered to be Bruce Lindsay, an employee of the IBM Research Center. He has contributed to the development of relational databases and has been involved in the development of the IBM System R enterprise database .

    In 1985, while studying at Berkeley University, Bruce and Jim Gray (James Nicholas Gray), an American scientist in the theory of computer systems, worked on the CAL-TSS OS. It was written specifically for the Control Process 6400 dual-processor mainframe [ PDF , p. 3], on which the military processed large amounts of data.

    Of course, during the development process there were bugs. But several of them were special - as soon as the engineers tried to fix them, they disappeared. At that time, Lindsay was just studying physics and the Heisenberg principle in particular. Suddenly it dawned on Lindsay - he and Gray became witnesses of a similar phenomenon: errors disappeared because observation affected the properties of the object. Hence the name “heisenbag” came from.

    Lindsay told this story in an interview with representatives of the Association of Computing Engineering (ACM) in 2003.

    Heisenbug Examples

    Users on the network and on thematic platforms like Stack Overflow shared some examples of heisenbags they met in their projects. One of the SO residents tried to calculate the area of ​​the figure between two curves with an accuracy of three decimal places. To debug the algorithm in C ++, he added the line:

    cout << current << endl;

    But as soon as he commented on it, the code stopped working and looped. The program was as follows :

    double up = 19.0 + (61.0/125.0);
    double down = -32.0 - (2.0/3.0);
    double rectangle = (up - down) * 8.0;
    doublef(double x){
    return (pow(x, 4.0)/500.0) - (pow(x, 2.0)/200.0) - 0.012;
    doubleg(double x){
    return -(pow(x, 3.0)/30.0) + (x/20.0) + (1.0/6.0);
    doublearea_upper(double x, double step){
    return (((up - f(x)) + (up - f(x + step))) * step) / 2.0;
    doublearea_lower(double x, double step){
    return (((g(x) - down) + (g(x + step) - down)) * step) / 2.0;
    doublearea(double x, double step){
    return area_upper(x, step) + area_lower(x, step);
    double current = 0, last = 0, step = 1.0;
    do {
    last = current;
    step /= 10.0;
    current = 0;
    for(double x = 2.0; x < 10.0; x += step) current += area(x, step);
    current = rectangle - current;
    current = round(current * 1000.0) / 1000.0;
    //cout << current << endl; //<-- COMMENT BACK IN TO "FIX" BUG
     } while(current != last);
    cout << current << endl;

    The essence of the heisenbug : when there is no printout, the program performs comparisons with high accuracy in the processor registers. Moreover, the accuracy of the result exceeds the capabilities of double. To output the value, the compiler returns the result of the calculations to the main memory - while the fractional part is discarded. And the subsequent comparison in while leads to the correct result. When a line is commented out, there is no implicit truncation of the fractional part. For this reason, the two values ​​in while always turn out to be unequal to each other. As a solution to the problem, one of the participants in the discussion suggested using an approximate comparison of floating point numbers.

    Another Heisenbag story shared by engineers working with the Smalltalk-80 language environmenton Unix. They noticed that the system crashed if you left it idle for a while. But after moving the mouse cursor, everything worked again as usual.

    The problem was with the Unix scheduler, which lowered the priority of tasks that are idle. At some point, the priority was reduced so much that the processes in Smalltalk did not have time to complete. The task stack grew and hung the program. When the user moved the cursor, the OS restored priority and everything returned to square one.

    Other * bugs

    There are a number of terms that describe all sorts of errors: Borbag, Mandelbug, Schrödinbag.

    Borbag , the opposite of Heisenbug, is a common mistake that is easy to find and fix. Named after Niels Bohr, who in 1913 proposed a simple and understandable model of the structure of the atom. According to this model, the electrons of an atom move in certain orbits, which means that their momentum and radius of motion can be predicted. Likewise, the appearance of Borbags can be predicted if the necessary conditions are created for them.

    / photo OLCF at ORNL CC BY

    Schrödingbug - a mistake that exists and does not exist at the same time until the developer looks at it. The name of the error was in honor of a famous thought experiment .

    ConcerningMandelbag , then this is a mistake due to which the system behaves erratically and unpredictably. The phenomenon is named after the physicist, mathematician and creator of fractal geometry Benoit Mandelbrot .

    What is the result

    There are many examples of Heisenbags (and other * bugs) . They are very difficult to find, but the causes are usually commonplace: an uninitialized variable, synchronization errors in a multi-threaded environment, or problems with dead code removal algorithms . It turns out that in order to deal with such errors, they need to be cut off even at the stage of application design.

    From the corporate IaaS blog:

    Also popular now: