Was it worth waiting so long to find a bug?

image1.png


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,000 lines of C, C ++ and Lua code. It allows you to create different game modes in voxel space. Supports multiplayer, and lots of community mods.



On November 10, 2018, Issue # 7852 was opened in the project's bug tracker - 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:



image2.png


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 reason was found only now - in 2020.



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



V636The '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 was created , where they established a connection between this bug and 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? ...



All Articles