What bugs did LibreOffce find in PVS-Studio?

Usually we check a project with PVS-Studio. This time it was different. We checked PVS-Studio with the help of LibreOffice. And then they could and vice versa check.

Introduction

Articles about project audits evoke a very different reaction from readers: from “How much can you advertise this?” To “Thank you so much! PVS-Studio is really a great tool. ”To be fair, I want to say that advertising specialists are not involved in the verification of the project, only the PVS-Studio developers and the translator are making efforts. The contribution of the analyzer to open source, of course there is not a small one. Developers are not always interested in feedback, but the verification letter is received and errors found are corrected. Using the example of the LibreOffice project, an article about which will also be available soon, I want to tell you about the impact of project checks on the analyzer itself and about the work done.

About the analyzer

PVS-Studio is a static analyzer that detects errors in the source code of C / C ++ applications. The possibilities of application and integration of the analyzer are constantly expanding and, besides the demonstration of opportunities, open-source projects are impartial testers for the analyzer.
')
The LibreOffice project turned out to be a good test for a static analyzer and made each of the PVS-Studio team work.

I'll tell you about the problems that we encountered during the test.

Memory leak

LibreOffice is built using MS Visual C ++ 2013 in Cygwin. The PVS-Studio Standalone utility has relatively recently acquired the ability to check any projects, without going into the details of the build system, simply turn on “Compiler Monitoring” and run the build project. Read more about this feature in the article: PVS-Studio now supports any build system on Windows and any compiler. Easy and out of the box . In short, from the running processes in Windows, the information needed to start the process in the same environment is extracted. So, for storing the launch string, current directory, environment variables, etc. allocated a few hundred kilobytes of unmanaged memory. If the process belongs to a supported compiler, then the information was copied into managed memory, unmanaged memory was released anyway, BUT, for environment variables, as it turned out, this was not done. For each process, an average of 500 kilobytes was not released. This did not lead to serious problems on the projects that were checked before (at least we did not notice that something was wrong and the users did not complain). Building LibreOffice by Make is accompanied by a huge number of processes that are not related to the compiler. In a few hours of assembly, more than one hundred thousand processes were launched, with 25 gigabytes in the end. After correcting this place, the size of the memory used by the monitoring program was reduced to 1.8 GB.

Long check

The entire build process, including the compilation of libraries, contained 12,245 source code files. Unfortunately, the process of checking such a number of files took about 15 hours, so some optimizations were carried out in the analyzer core, which allowed the project to double-check in 9 hours. This is 2 times more than the project build time, but this is already quite adequate and acceptable speed of work.

Complexity of the analysis

If the analyzer fails to parse any constructs in the source code, then it issues V001 messages to this file. This section of code is skipped by the analyzer and in very rare cases affects the results of the check. However, the V001 messages on this project have been studied and corrected.

Old ways format

When checking the project, system paths were found in the old format, for example, “C: /PROGRA~2/MICROS~4.0/VC/include”. This format is fully supported by the analyzer's core and plug-in, but filtering messages on system files did not work, so the appropriate changes were made.

Failed serialization

This problem does not quite relate to the products of PVS-Studio. In the PVS-Studio Standalone utility, in which LibreOffice was tested, file navigation has recently been improved, which now allows you to navigate through included headers and search for types and variables in dependent files. All dependencies are collected during the scan and saved near the * .plog file. Unfortunately, the standard class System.Runtime.Serialization.Formatters.Binary.BinaryFormatter cannot serialize large-volume structures — an internal exception occurs, so the Protocol Buffers library is now used, which does an excellent job with the same task.

Conclusion

The result of the LibreOffice check was an article that is designed to make one more open-source project better, and good edits in PVS-Studio products. An article about an error found in LibreOffice will be published in the coming days. And we want to say thanks to the project LibreOffice, which helped us make our analyzer better!

Additional links

1. PVS-Studio now supports any build system on Windows and any compiler. Easy and out of the box
2. New mechanism to suppress unnecessary messages analyzer