Was it worth waiting so long to find a bug?

Surely you wondered whose code is better: an open source project or a closed one? After reading our blog, you might think that all the bugs were collected by open source projects. But it is not so. Errors are present in all projects, regardless of the way they are stored. And the quality will be better where it is improved. This is a small note about how a bug was fixed in one project for 2 years, but could have done it in 5 minutes.

Chronology of events

Minetest Is an open source cross-platform game engine containing about 200 thousand lines of code in C, C ++ and Lua. It allows you to create different game modes in voxel space. Supports multiplayer, and lots of community mods.

November 10, 2018 in the project’s bugtracker was opened Issue # 7852 – item_image_button[]: button too small…

The description is as follows:

The button is too small resulting in the image exceeding its borders. Button should be the same size as inventory slots. See example below (using width and height of 1).

And a screenshot:

In the screenshot, you can see a slight outflow of pictures outside the border of the inner area of the buttons. The bug was noticed back in 2018, and the cause was found only now – in 2020.

The next development in this remarkable story was the publication of a technical article “PVS-Studio: Analysis of pull requests in Azure DevOps using self-hosted agents“in July 2020. To give an example of integrating the analyzer into Azure DevOps, the same game was chosen – minetest. The article lists several errors found, but we are interested in one specific one:

V636 The ‘rect.getHeight () / 16’ expression was implicitly cast from ‘int’ type to ‘float’ type. Consider utilizing an explicit type cast to avoid the loss of a fractional part. An example: double A = (double) (X) / Y ;. hud.cpp 771

void drawItemStack(....)
{
  float barheight = rect.getHeight() / 16;
  float barpad_x = rect.getWidth() / 16;
  float barpad_y = rect.getHeight() / 16;

  core::rect<s32> progressrect(
    rect.UpperLeftCorner.X + barpad_x,
    rect.LowerRightCorner.Y - barpad_y - barheight,
    rect.LowerRightCorner.X - barpad_x,
    rect.LowerRightCorner.Y - barpad_y);
}

When dividing the width and height values by 16, the fractional part of the result is discarded, because integer division.

And now, six months later, the results of the analysis were noticed by the game developers, and Issue 10726 – Fix errors found by professional static code analyzer, where we linked this bug with Issue # 7852… This rounding and distorted button sizes.

conclusions

Using static code analyzers allows you to save a lot of time on identifying errors in your code. It can be argued that the described bug is insignificant, but our experience shows that this is a typical life cycle of an error of any criticality.

Let’s say there was a serious bug here. All efforts would be thrown at fixing it, and in an hour of debugging they would find and fix it. But the analyzer would still find it in a couple of minutes.

Thus, we can conclude that automatic methods of finding errors bring undeniable benefits to the developed project. Tools like PVS-Studio should be seen as an addition to codereview with other programmers, not a replacement for this process.

If you want to share this article with an English-speaking audience, please use the translation link: Svyatoslav Razmyslov. Did It Have to Take So Long to Find a Bug ?.