Chromium: the Sixth Project Check and 250 Bugs

This introduction begins a series of articles dealing with a recurrent check of a Chromium project using PVS-Studio static code analyzer. The articles include various patterns of errors and recommendations that reduce the likelihood of such errors appearing in code. However, to start with, some sort of an introduction should be presented, which will answer a number of questions in advance, and present all of the bugs discovered to the developers of Chromium, so that they can start fixing them without waiting for the end of this article series.

Background

My name is Andrey Karpov and I am the evangelist of static analysis as a whole and of the PVS-Studio static analysis tool in particular. However, the term "technical evangelist" is already outdated and was replaced by "developer advocate".

I dedicate a lot of time for writing material on improving code quality and increasing reliability of programs. Now I have a new reason to write more articles on this topic, which is a check of an open source project Chromium using PVS-Studio. This is a big project, and in any large project you can find bugs of various kinds living in it. Such diversity allows to review several interesting topics related to the causes of these bugs and ways of preventing them.

It is worth noting that this is not the first article dedicated to the Chromium project. Here are my previous publications:

Every time we checked this project, a huge number of errors were discovered in it. The new check is not an exception. Moreover, since the PVS-Studio analyzer is getting better at detecting errors, at first I just didn't know what to do with all of them. Briefly looking through the report, I wrote down about 250 errors and pondered. Shall I describe all the 250 errors in one article? It will be some kind of horror: long, boring and uninteresting. Separate this account into several parts? It will not do better, as we will get several boring articles instead of one.

Then I decided to divide bugs by type and consider them separately. Besides, I decided not to just describe the errors, but to suggest some methods of dealing them in addition to static code analysis. It is far better not to make an error than to find it then using static/dynamic code analysis/or something else. It is even worse, if a user finds errors. So, if you can improve your coding style in a manner that reduces the possibility of a bug occurrence, than this topic is worth talking about. This will be the matter of our series of articles.

Before considering the patterns of errors, I need an introduction that you are reading. For example, I need to explain why I haven't found enough energy to carefully study the report, why I can't say about the percentage of false positives and where you can get acquainted with all errors that I discovered.

Checking the project

At the end of 2017, my colleague Svyatoslav Razmyslov downloaded source codes of the Chromium project, did some magic with them and gave me the generated project for Visual Studio and a report of PVS-Studio. Unfortunately, it turned out to be impossible to work with the solution in Visual Studio environment. The environment could not stand the solution containing 5021 project.

Everything was incredibly slow, and the environment crashed after a while. That's why I studied the report using PVS-Studio Standalone. It's certainly not as convenient to use as the familiar Visual Studio environment, but quite acceptable.

It should be reminded, that the Chromium project is very large. Not just large. This is an ENORMOUS project.

The Chromium project and the libraries used in it consist of 114 201 files in C and C++. The number of lines of code is 30 263 757. Comments constitute 16%.

It is already an achievement, that PVS-Studio can check a project that large :).

Things I've Found

During Christmas holidays, I spent three evenings looking through the report and wrote down about 250 fragments of code, which, in my opinion, require reviewing and correction. I confess that I have not found time and energy to study the report carefully. I glanced through many warnings very quickly, and even ignored some of them, when I became bored of some kind of error. I will give more details about it in the next chapter.

It is important that I found a lot of bugs, which will be enough to be described in a several articles. By the time I finish publishing the last line, the information about errors in the project may become slightly out of date. But it doesn't matter. My purpose is to demonstrate the methodology of static code analysis and share with readers some advice on coding style.

I cited the errors that I have found in a separate file so that developers of Chromium and the libraries could correct them without waiting for the end of the series of articles. This also had to be done by the reason that, perhaps, not all of the warnings will be presented in the articles.

Link to the file with a description of the discovered defects is available here: chromium.txt.

Why didn't I manage to view the report carefully?

I have not configured the analyzer to reduce the number of false positives. Therefore, false warnings hindered me from reviewing the report, and I was often skipping similar messages, not looking at them.

Even more, I skipped fragments of code, where it was not clear at once if there was an error or not. A lot of warnings and one of me. If I started looking carefully at the code, I would write articles only in several months.

Let me demonstrate with examples why some warnings are so difficult to understand, especially if it's unfamiliar code. And I'm unfamiliar with ALL code in Chromium.

So, PVS-Studio analyzer had issued a warning on one of files of V8 project:

The truncated flag has to be true, if the text is too long, i.e. if the condition if (len > kMaxShortPrintLength) is executed.

However, if the text is too long, then exit from the function occurs above.

This is the reason why truncated is always false and three dots will not be added to the end. And even now, after ascertaining the reason for which the analyzer issues a warning, I don't know how the code should be written. Either you need to leave the function at once, and the code which adds the dots is redundant, or the points are indeed needed, and the first check which prematurely terminates the function should be removed. It is very, very difficult to review the errors in third party code. PVS-Studio analyzer issued a lot of V547 warnings. I looked through only the 10th part of them. Therefore, if you undertake to view them closely, you will find a lot more errors than I cited.

Here's another example explaining why I was bored to work with all those warnings.

Unlike the previous case, here everything is simple. The analyzer is surely right, stating that the second condition is always true.

However, it is not an error, but a redundant code. Is this code worth editing? Difficult question. By the way, this is the reason why it is much better to write code right under the supervision of the analyzer, rather than to heroically make your way through the warnings during one-time runs.

If the analyzer was used regularly, most likely the redundant code would not even get into the version control system. The programmer would see the warning and write more gracefully. For example, as follows:

if (bad_message) {
*error = "An action of a rule set had an invalid "
"structure that should have been caught "
"by the JSON validator.";
}
if (!error->empty() || bad_message)
return std::move(error_result);

I hope I could explain why I have not studied the report carefully. It's a big job that requires a lot of time.

Percentage of False Positives

I can't say what is the percentage of false positives. Firstly, I was not even able to look through the entire log to the end and I do not know the exact number of errors detected by PVS-Studio. Secondly, there is no point to talk about the percentage of false positives without the preliminary configuration of the analyzer.

Of course, it is possible to perform such a configuration for Chromium, but it is unreasonable to do so, aiming just to cite some numbers in the article. It's a big job that we are ready to do, but not for free. Google may well involve our team to configure the analyzer and, at the same time, to fix all found errors. Yes, you can think of it as a hint.

Undoubtedly, the configuration will give a good result. For example, about a half of all false positives is related to the use of DCHECK macro in code.

PVS-Studio informs: V1004 CWE-476 The 'other' pointer was used unsafely after it was verified against nullptr. Check lines: 621, 622. values.cc 622

In terms of the analyzer, a check of the pointer other for equality to nullptr is performed. But regardless of whether the other is a null pointer or not, its dereference will occur further. Analyzer considers such actions as dangerous.

DCHECK macrois a kind of assert-macros. The analyzer knows what is assert, but as for DCHECK - it does not. To explain better what is happening, I will write pseudo code:

This is how the analyzer considers the code. Initially, the pointer is checked for equality to nullptr. If the pointer is null, then the function LogMessage is called. Yet the function is not marked as one that does not return control. It means, that despite the fact if the ptr is null or not, the function continues to be executed.

Further on, the pointer is dereferenced. But there was a check, where it was checked for null! Therefore, the pointer might be null and the analyzer indicates about the problem in code. And this is how the analyzer issues a lot of correct but useless warnings.

By the way, this implementation of macro confuses not only PVS-Studio. So, for the analyzer, which is built into Visual Studio, a special "backup" is made:

If you also implement a similar backup for the PVS-Studio analyzer, the situation with false positives will change dramatically. According to my estimate, a half of false positives will immediately disappear. Yes, exactly a half. The thing is that theDCHECK macro is used so many times.

Other Publications

This is the end of the introductory article and here I'll gradually give links to other articles. Thank you for your attention.

We use cookies for the analysis of events to improve our content and make user interaction more convenient. By continuing the view of our web-pages you accept the terms of using these files. You can find out more about cookie-files and privacy policy or close the notification, by clicking on the button.
Learn More →