February 24, 2015 at 10:24What bugs did LibreOffce find in PVS-Studio?
We usually check with PVS-Studio a project. This time it turned out differently. We tested PVS-Studio with LibreOffice. And then, nevertheless, they could and vice versa check.
Introduction
Articles about project inspections provoke a very different reaction from readers: from “How much can this be advertised?” To “Thank you so much!” PVS-Studio is really a great tool. ”In fairness, I want to say that advertising experts do not take part in the verification of the project, only PVS-Studio developers and translators make efforts. The analyzer's contribution to open-source is certainly not small. Developers are not always interested in feedback, but they receive a letter of verification and correct errors found. Using the LibreOffice project as an example, an article about which will also be available soon, I want to talk about the impact of project checks on the analyzer itself and the work done.
About the analyzer
PVS-Studio is a static analyzer that detects errors in the source code of C / C ++ applications. Possibilities of application and integration of the analyzer are constantly expanding and, in addition to demonstrating the capabilities, open-source projects act as unbiased 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 when checking.
Memory leak
LibreOffice is built using MS Visual C ++ 2013 in Cygwin. The PVS-Studio Standalone utility has recently acquired the ability to check any projects without going into the details of the assembly system, just turn on “Compiler Monitoring” and start building the project. You can 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, the information needed to start the process in the same environment is extracted from running processes in Windows. So for storing the launch line, current directory, environment variables, etc. Several hundred kilobytes of unmanaged memory are allocated. If the process belongs to a supported compiler, then the information was copied to managed memory, unmanaged memory was freed up in any case, BUT, for environment variables, as it turned out, this was not done. For each process, an average of 500 kilobytes was not released. On previously verified projects, this did not lead to serious problems (at least we did not notice that something was wrong and users did not complain). Build by Make by LibreOffice is accompanied by a huge number of running processes that are not related to the compiler. Within a few hours of assembly, more than one hundred thousand processes were launched, as a result, 25 gigabytes were “dripped”. After fixing this place, the memory size used by the monitoring program decreased to 1.8 GB.
Long check
The entire assembly process, including compiling libraries, contained 12,245 source 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 that allowed to double-check the project in 9 hours. This is 2 times the project assembly time, but it is already quite adequate and acceptable speed.
Difficulty analysis
If the analyzer fails to parse any constructs in the source code, then it will issue V001 messages to this file. The analyzer skips such a section of code and, in very rare cases, affects the results of verification. However, the messages of V001 on this project have been studied and corrected.
Old path 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 core and the plugin, but filtering messages on system files did not work, therefore, the corresponding changes were made.
Failed serialization
This problem does not apply to PVS-Studio products. 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 stored near the * .plog file. Unfortunately, the standard class System.Runtime.Serialization.Formatters.Binary.BinaryFormatter fails to serialize large-volume structures - an internal exception is thrown, so the Protocol Buffers library is now used , which does an excellent job of this.
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 errors found in LibreOffice will be published in the coming days. And we want to say thanks to the LibreOffice project, which helped us make our analyzer better!