Compiler Monitoring System in PVS-Studio

Introduction

The PVS-Studio Compiler Monitoring system (CLMonitoring) was designed for "seamless" integration of the PVS-Studio static analyzer into any build system under Windows that employs one of the preprocessors supported by the PVS-Studio.exe command-line analyzer (Visual C++, GCC, Clang, Borland C++) for compilation.

To perform correct analysis of the source C/C++ files, the PVS-Studio.exe analyzer needs intermediate .i files which are actually the output of the preprocessor containing all the headers included into the source files and expanded macros. This requirement defines why one can't "just take and check" the source files on the disk - besides these files themselves, the analyzer will also need some information necessary for generating those .i files. Note that PVS-Studio doesn't include a preprocessor itself, so it has to rely on an external preprocessor in its work.

As the name suggests, the Compiler Monitoring system is based on "monitoring" compiler launches when building a project, which allows the analyzer to gather all the information essential for analysis (that is, necessary to generate the preprocessed .i files) of the source files being built. In its turn, it allows the user to check the project by simply rebuilding it, without having to modify his build scripts in any way.

This monitoring system consists of a compiler monitoring server (the command-line utility CLMonitor.exe) and an UI client integrated into the Standalone version of PVS-Studio and responsible for launching the analysis (CLMonitor.exe can be also used as a client when launched from the command line).

In the current version, the system doesn't analyze the hierarchy of the running processes; instead, it just monitors all the running processes in the system. It means that it will also know if a number of projects are being built in parallel and monitor them.

Working principles

CLMonitor.exe server monitors launches of processes corresponding to the target compiler (for example cl.exe for Visual C++ and g++.exe for GCC) and collects information about the environment of these processes. Monitoring server will intercept compiler invocations only for the same user it was itself launched under. This information is essential for a correct launch of static analysis to follow and includes the following data:

  • the process main folder
  • the full process launch string (i.e. the name and all the launch arguments of the exe file)
  • the full path to the process exe file
  • the process environment system variables

Once the project is built, the CLMonitor.exe server must send a signal to stop monitoring. It can be done either from CLMonitor.exe itself (if it was launched as a client) or from Standalone's interface.

When the server stops monitoring, it will use the collected information about the processes to generate the corresponding intermediate files for the compiled files. And only then the PVS-Studio.exe analyzer itself is launched to carry out the analysis of those intermediate files and output a standard PVS-Studio's report you can work with both from the Standalone version and any of the PVS-Studio IDE plugins.

Getting started with CLMonitor.exe

Note: in this section, we will discuss how to use CLMonitor.exe to integrate the analysis into an automated build system. If you only to check some of your projects manually, consider using the UI version of Standalone as described in the next section.

CLMonitor.exe is a monitoring server directly responsible for monitoring compiler launches. It must be launched prior to the project build process. After launching the server in monitoring mode, it will trace the invocations of supported compilers.

The supported compilers are:

  • Microsoft Visual C++ (cl.exe) compilers
  • C/C++ compilers from GNU Compiler Collection (gcc.exe, g++.exe)
  • Clang (clang.exe) compiler and other Clang-based compilers (for example Borland C++ 64 - bcc64.exe)
  • 32-bit Borland C++ (bcc32.exe) compiler

But if you want the analysis to be integrated directly into your build system (or a continuous integration system and the like), you can't "just" launch the monitoring server because its process blocks the flow of the build process while active. That's why you need to launch CLMonitor.exe with the monitor argument in this case:

CLMonitor.exe monitor

In this mode, CLMonitor will launch itself in the monitoring mode and then terminate, while the build system will be able to continue its work. At the same time, the second CLMonitor process (launched from the first one) will stay running and monitoring the build process.

Since there are no consoles attached to the CLMonitor process in this mode, the monitoring server will - in addition to the standard stdin\stdout threads - output its messages into a Windows event log (Event Logs -> Windows Logs -> Application).

Note: for the monitoring server to run correctly, it must be launched with the same privileges as the compiler processes themselves.

To ensure correct logging of messages in the system event logs, you need to launch the CLMonitor.exe process with elevated (administrative) privileges at least once. If it has never been launched with such privileges, it will not be allowed to write the error messages into the system log.

Notice that the server only records messages about its own runtime errors (handled exceptions) into the system logs, not the analyzer-generated diagnostic messages!

Once the build is finished, run CLMonitor.exe in the client mode so that it can generate the preprocessed files and call the static analyzer itself:

CLMonitor.exe analyze -l "c:\test.plog"

As the -l argument, the full path to the analyzer's log file must be passed.

When running as a client, CLMonitor.exe will connect to the already running server and start generating the preprocessed files. The client will receive the information on all of the compiler invocations that were detected and then the server will terminate. The client, in its turn, will launch preprocessing and PVS-Studio.exe analyzer for all the source files which have been monitored.

When finished, CLMonitor.exe will save a log file (C:\test.plog) which can be viewed in any PVS-Studio IDE plugin or the Standalone version (PVS-Studio -> Open/Save -> Open Analysis Report).

You can also use the analyzer message suppression mechanism with CLMonitor through the -u argument:

CLMonitor.exe analyze -l "c:\ptest.plog" -u "c:\ptest.suppress" -s

The -u argument specifies a full path to the suppress file, generated through the 'Message Suppression' dialog in Standalone (Tools|Message Suppression...). The optional -s argument allows you to append the suppress file specified through the -u with newly generated messages from the current analysis run.

Compiler monitoring from Standalone

For the "manual" check of individual projects with CLMonitor, you can use the interface of the Standalone version which can be launched from the Start menu (PVS-Studio -> Standalone).

To start monitoring, open the dialog box: Tools -> Analyze Your Files... (Figure 1):

Figure 1 - The compiler monitoring start dialog box

Figure 1 - The compiler monitoring start dialog box

Click "Start Monitoring" button. CLMonitor.exe process will be launched and the environment main window will be minimized.

Start building your project, and when it's done, click the "Stop Monitoring" button in the bottom right-hand corner of the window (Figure 2):

Figure 2 - The monitoring management dialog box

Figure 2 - The monitoring management dialog box

If the monitoring server has successfully tracked all the compiler launches, the preprocessed files will be generated first and then they will be analyzed. When the analysis is finished, you will see a standard PVS-Studio's report (Figure 3):

Figure 3 - The resulting output of the monitoring server and the analyzer

Figure 3 - The resulting output of the monitoring server and the analyzer

The report can be saved as an XML file (a .plog file): File -> Save PVS-Studio Log As...

Conclusion

Despite the convenience of the "seamless" analysis integration into the automated build process (through CLMonitor.exe) employed in this mode, one still should keep in mind the natural restrictions inherent in this mode - particularly, that a 100% capture of all the compiler launches during the build process is not guaranteed, which failure may be caused both by the influence of the external environment (for example antivirus software) and the hardware-software environment specifics (for example the compiler may terminate too quickly when running on an SSD disk while CPU's performance is too low to "catch up with" this launch).

That's why we recommend you to provide whenever possible a complete integration of the PVS-Studio static analyzer with your build system (in case you use a build system other than MSBuild) or use the corresponding PVS-Studio IDE plugin.


Do you make errors in the code?

Check your code
with PVS-Studio

Static code analysis
for C, C++ and C#

goto PVS-Studio;