Bohrbug: What It Is, Causes, and Methods to Fix It

What Is a Bohrbug?

Bohrbug is a type of software error that manifests deterministically: given the same input data, it always produces the same failure. The term was introduced into scientific circulation by researchers Jim Gray and Andreas Reuter in the book “Transaction Processing: Concepts and Techniques” (1993).

Unlike a Mandelbug, which chaotically changes its behavior, Bohrbug is stable: a developer can reproduce it blindfolded by feeding the system the same parameters. This makes it an ideal candidate for step-by-step debugging in an IDE.

Bohrbug occurs at all stages of the software lifecycle — from development to production. It is often discovered during testing, since QA engineers run repetitive scenarios that are guaranteed to trigger the failure.

Definition by Gray and Reuter

According to the classification by Gray and Reuter, a Bohrbug is a defect that satisfies three conditions: a fixed set of input data, the same system state, and the same failure result. If at least one condition is violated, the bug ceases to be “Bohr.”

The authors emphasize that a Bohrbug is not necessarily a simple error. It can be arbitrarily complex in logic, but its determinism distinguishes it from all other types of failures in the classification.

Origin of the Name Bohrbug

The name Bohrbug comes from the Danish physicist Niels Bohr, creator of the planetary model of the atom. The analogy is simple: just as an electron in Bohr’s model moves along a strictly fixed orbit, this bug repeats the same behavior on every run.

Gray and Reuter chose this name to contrast deterministic errors with chaotic ones, which they called Mandelbug — after the mathematician Benoit Mandelbrot, founder of fractal theory and chaos theory.

Interestingly, in English-language literature, the term Bohrbug is often used as a synonym for “deterministic error,” although it is less common in Russian-speaking environments. Most developers simply call such bugs “reproducible errors.”

Key Characteristics of Bohrbug

Bohrbug has a set of distinctive properties that help identify it among other types of software defects. Let’s look at each characteristic in detail.

Determinism

The main feature of Bohrbug is complete predictability. If the application crashed with certain input data on a developer’s machine, it will crash exactly the same way on a tester’s machine and in production. No random factors.

Reproducibility

Bohrbug reproduces in 100% of attempts. This means debugging does not require special tools — a standard IDE and debugger are sufficient. The developer sets a breakpoint, launches the application, provides input data, and steps through the code.

Stability over Time

If a Bohrbug is not fixed, it will reproduce in any version of the program until it is corrected. Temporal factors — CPU load, phase of the moon, time of day — do not affect its manifestation.

Common Causes of Bohrbug

The causes of Bohrbug can be divided into several categories. Understanding these categories helps find the root of the problem faster.

Logic Errors

An incorrectly constructed condition is the most common cause of Bohrbug. For example, a developer used the `||` operator instead of `&&`, causing a code branch to execute incorrectly every time the function is called with certain arguments.

Boundary Condition Errors

Using the operator `<=` instead of `<` or the reverse situation is a classic source of Bohrbug. If a loop should execute 10 times but runs 11 due to an incorrect condition, that is a deterministic error that will manifest on every run.

Incorrect Constants and Magic Numbers

Hard-coded constants that do not match business logic create stable failures. For example, a server connection timeout set to 100 milliseconds instead of 5000 — the connection will break on every request.

How to Detect Bohrbug in Code

Detecting a Bohrbug is the easiest task for a developer compared to other types of bugs. The deterministic nature allows the use of standard debugging methods.

public class DiscountCalculator {
    public double calculate(double amount, boolean isPremium) {
        // Bug: premium users get 5% discount instead of 10%
        if (isPremium) {
            return amount * 0.95;
        }
        return amount * 0.90;
    }
}

In this example, the Bohrbug is obvious: when `calculate(1000, true)` is called, the method always returns 950 instead of 900. A simple unit test with fixed input data will instantly reveal the problem.

Unit Testing as the Primary Method

For detecting Bohrbug, unit tests are the most effective tool. It is enough to cover the function with a set of tests with various boundary values, and the deterministic error will appear on the first run.

Step-by-Step Debugging

Once a Bohrbug is detected, step-by-step debugging in an IDE is the best way to find the root cause. The developer sets a breakpoint at the function entry and goes through each line, observing variable values.

Bohrbug vs Other Types of Bugs

Bohrbug differs from other types of software errors by a key feature — determinism. Let us compare them in a table.

Bohrbug is the only type of error that can be reliably reproduced under controlled conditions. This makes it the safest from a diagnostic standpoint, but no less dangerous for the user.

Why Bohrbug and Heisenbug Are Confused

Heisenbug is a bug that disappears when you try to debug it. Unlike Bohrbug, Heisenbug may not reproduce in a debugger due to changes in code execution timings. Beginner developers often confuse these two types.

Bohrbug Code Example

Let’s look at a real example of a Bohrbug in an e-commerce application. The function calculates the total order cost including tax.

public double calculateTotal(double subtotal, double taxRate) {
    // Bug: developer set taxRate as percentage
    // but forgot to divide by 100
    return subtotal + (subtotal * taxRate);
}

When `calculateTotal(1000, 20)` is called, the function returns 21000 instead of the expected 1200. This is a classic Bohrbug: the same input data always leads to the same incorrect result. The fix is trivial — add division by 100.

Fixed Version

After the fix, the function correctly processes the tax rate:

public double calculateTotal(double subtotal, double taxRatePercent) {
    return subtotal + (subtotal * taxRatePercent / 100.0);
}

This example clearly shows that a Bohrbug can be caused by a simple mathematical error. That is why code review and unit tests are the main tools for preventing such defects.