Cov Deploy Install Guide

Coverity 2019.
09 Installation and Deployment Guide :

Planning, Installation, Tuning, and Supported Platforms Guidance for Coverity Analysis, Coverity Platform, and Coverity
Desktop.
Copyright 2019 Synopsys, Inc. All rights reserved worldwide.
Table of Contents
About this guide .............................................................................................................................. iii
1. Coverity product overview .................................................................................................... iii
2. Installation and deployment overview .................................................................................... v
1. Installing Coverity Platform components ........................................................................................ 1
1.1. Installing Coverity Connect ................................................................................................ 2
1.2. Coverity Platform installation modes ................................................................................... 7
1.3. Advanced installation options ........................................................................................... 17
1.4. Post-installation notes ...................................................................................................... 22
1.5. Installing Coverity Reports ............................................................................................... 24
1.6. Coverity Reports installation modes .................................................................................. 24
1.7. Platform Updater ............................................................................................................. 25
2. Installing Coverity Analysis components ...................................................................................... 30
2.1. Installing Coverity Analysis ............................................................................................... 31
2.2. Coverity Analysis installation modes ................................................................................. 34
2.3. Coverity Analysis license options ..................................................................................... 38
2.4. Using an archive file to install Coverity Analysis ................................................................ 51
3. Installing Coverity Desktop components ...................................................................................... 52
3.1. Installing Coverity Desktop for Eclipse, Wind River Workbench, QNX Momentics, and IBM
RTC ....................................................................................................................................... 52
3.2. Installing Coverity Desktop for Microsoft Visual Studio ....................................................... 57
3.3. Installing Coverity Desktop for IntelliJ IDEA and Android Studio ......................................... 58
3.4. Installing Coverity Analysis for local analysis ..................................................................... 59
4. Installing Architecture Analysis .................................................................................................... 60
5. Deployment planning .................................................................................................................. 64
5.1. Deployment checklist ....................................................................................................... 64
5.2. How Coverity products integrate into a build system .......................................................... 66
5.3. Coverity Analysis deployment models ............................................................................... 67
5.4. Coverity Connect deployment options ............................................................................... 70
5.5. Other deployment models and features ............................................................................ 75
6. Hardware recommendations and requirements ............................................................................ 78
6.1. Coverity Connect hardware .............................................................................................. 78
6.2. Coverity Analysis hardware .............................................................................................. 79
7. Supported platforms ................................................................................................................... 83
7.1. Coverity Connect and Coverity Policy Manager platforms .................................................. 83
7.2. Coverity Analysis and Dynamic Analysis ........................................................................... 85
7.3. Coverity Test Advisor SCM and platform support ............................................................ 112
7.4. Architecture Analysis ..................................................................................................... 117
7.5. Coverity Desktop ........................................................................................................... 119
8. Coverity Connect system tuning, maintenance, and monitoring ................................................... 128
8.1. Post-installation: what's next? ......................................................................................... 128
8.2. Coverity Connect system and database tuning ................................................................ 130
8.3. Monitoring and diagnosing Coverity Connect performance ............................................... 133
8.4. Deployment scenarios .................................................................................................... 140
A. Coverity Glossary ..................................................................................................................... 153
B. Legal Notice ............................................................................................................................ 165
B.1. Legal Notice .................................................................................................................. 165
ii
About this guide
Table of Contents
1. Coverity product overview ............................................................................................................ iii
2. Installation and deployment overview ............................................................................................ v
The Coverity 2019.09 Installation and Deployment Guide contains information to help you plan for a
Coverity product deployment. This guide is intended for system architects, deployment architects, and
build engineers who are responsible for the planning and installation of Coverity tools.
Product functionality, configuration, and operation instructions that are unrelated to deployment are not
covered in this manual, so it is assumed that you have a knowledge of Coverity products and features.
For more detailed information about Coverity tools, refer to the following documentation:
• Coverity Platform 2019.09 User and Administrator Guide - Guidance for system administrators and end
users of Coverity Connect, Coverity Policy Manager, and Coverity Integrity Report.
• Coverity Analysis 2019.09 User and Administrator Guide - Guidance for build engineers or system
architects to integrate and configure cov-analysis tools with the nightly build system.
The complete documentation set for Coverity products can be found under the root installation directory
of either Coverity Platform or Coverity Analysis:
<coverity_product_install_root>/doc/
1. Coverity product overview

There are two installer applications that Coverity provides, Coverity Analysis and Coverity Platform. The
following figure shows the relationship of issues found by Coverity tools (and third-party analyses) to the
Coverity components that help you manage and fix them.
iii
About this guide
Coverity Analysis Installation
Coverity Analysis components and extensions are built on top of Coverity (Coverity Analysis), the set
of foundational technologies that support the use of Coverity checkers to detect quality defects (Quality
issues), Potential Security Vulnerabilities (Security issues), test violations (Test Advisor issues), and Java
runtime defects (Dynamic Analysis issues).
• Analysis Components
• Coverity Analysis (formerly called Coverity Static Analysis)
• Test Advisor
• Dynamic Analysis
iv
About this guide
• Architecture Analysis
• Analysis Extensions
• Third Party Integration Toolkit supports the addition of issues found by third-party products to the
Coverity Connect database.
• Compiler Integration Toolkit (CIT) allows you to extend the set of compilers that can be used to build
source code for Coverity analyses.
• Coverity Extend SDK supports the development of custom checkers.
• Coverity Platform Installation
Coverity Platform components support Web-based management of issues found by Coverity analyses
and third-party tools.
• Coverity Desktop for Eclipse and for Microsoft Visual Studio supports IDE-based analysis,
management, and remediation of issues. Coverity Desktop relies on Coverity to support local
analyses.
• Coverity Connect is a Web-based application that helps software developers and team leaders
manage and fix issues found through Coverity analyses and third party tools. The Coverity Connect
interface provides descriptions of the issues found by Coverity analyses and shows where the issues
exist in the source code.
• Downloads: Coverity Connect also provides access to downloads for the Coverity Desktop
plug-ins and the Coverity Reports installer. For details about these downloads, see Section 1.1,
“Installing Coverity Connect”.
• Extensions: Coverity Connect also provides access to the WSDL files for the Configuration and
Defect services of the Coverity Platform Web Services API.
• Coverity Policy Manager is a Web-based solution for code governance that enables software
development organizations to set policies for code quality and security, and then manage, monitor,
and report on these policies as code is tested. Coverity Policy Manager provides managers and
leaders who have cross-organizational responsibilities with the insight needed to better align quality
goals with business objectives, to enforce standards across the development organization, and to
manage third-party code dependencies.
2. Installation and deployment overview

• Deployment planning represents the research and planning phase of the overall deployment. This
section provides information to help you identify your organization's needs.
• Installation covers the phase during which you work from specifications and plans created during the
deployment planning phase to install the Coverity tools. Installation is covered in several sections of
this guide: Chapter 1, Installing Coverity Platform components, Chapter 2, Installing Coverity Analysis
v
About this guide
components, Chapter 3, Installing Coverity Desktop components, Chapter 4, Installing Architecture

Analysis.
• Coverity Connect system tuning, maintenance, and monitoring provides recommendations for
system tuning and database maintenance procedures to ensure optimal performance. In addition, this
section also provides tips for monitoring your system so that you can collect trend data to track the
performance of your system over time.
• Supported Platforms provides matrices of Coverity products, compilers, components, and their
supported operating systems and runtime environments.
Coverity deployment follows a process of planning, designing, and implementing the Coverity tools. The
following diagram shows the deployment cycle and the cycle's phases that are discussed in this guide:
vi
About this guide
2.1. Deployment planning
Deployment planning is a critical step to successfully implement Coverity tools. Each organization
has its own set of goals, requirements, and priorities. Successful deployment planning is the result of
preparation, analysis, and implementation. Errors that might occur anywhere during the planning process
can result in a system that might under-perform, be difficult to maintain, be too expensive to operate,
could waste resources, or could be unable to scale to meet your organization's increasing needs.
vii
About this guide
Understanding the Coverity system architecture

During this step, you review the system deployment options to understand how Coverity products
integrate with your existing build system, and choose the hardware infrastructure so that your
deployed system runs efficiently and quickly. For more information, see Chapter 5, Deployment
planning.
Hardware specifications
This section provides hardware recommendations to implement your hardware infrastructure on
which Coverity products will run.
Security hardening
For information on maintaining the Coverity installation in a secure manner, please see "Securing
Coverity Connect" in the Coverity Platform 2019.09 User and Administrator Guide.
2.2. Implementation
During the implementation phase of the deployment cycle, you work from specifications and plans
created during the deployment planning phase to build and test the deployment, ultimately rolling out the
deployment into production.
Hardware setup
The implementation of the hardware that will host the Coverity deployment.
Installing Coverity products

The process of installing the Coverity products based on the decisions that you made during the
deployment planning phase. For installation instructions, see Chapter 1, Installing Coverity Platform
components.
Database and system tuning

Tuning the database and system settings for Coverity Connect. For more information, see
Section 8.2, “Coverity Connect system and database tuning”.
Deployment scenario analysis

This section provides deployment use cases that describe the steps and decisions that Coverity
customers have made to successfully integrate Coverity products into their system. You can review
these use cases and apply the solutions to your deployment planning. For more information, see
Section 8.4, “Deployment scenarios ”
Bring into production

Get the system up and running so that all components are functioning together (also see "System
Configuration" below).
2.3. Operation
The Operating phase consists of post-deployment tasks to configure, maintain, and monitor your
organization's Coverity deployment.
System configuration
The "What's Next" list provides an overview of tasks that you need to complete in order to set up your
system (mainly administrative tasks).
viii
About this guide
System maintenance
System maintenance provides recommendations for you to enable features and settings that will
maintain the size of the Coverity Connect database.
Monitoring the system

Monitoring the system is an important part of the process. It is suggested that you record trend
data over time so you can make sure that the entire system is performing optimally. Guidelines for
monitoring are provided in Section 8.3, “Monitoring and diagnosing Coverity Connect performance”.
System enhancements and upgrades

This step represents the ongoing improvements to the deployment, through upgrading new versions
and implementing new features.
ix
Chapter 1. Installing Coverity Platform components
Table of Contents
1.1. Installing Coverity Connect ........................................................................................................ 2
1.2. Coverity Platform installation modes ........................................................................................... 7
1.3. Advanced installation options ................................................................................................... 17
1.4. Post-installation notes .............................................................................................................. 22
1.5. Installing Coverity Reports ....................................................................................................... 24
1.6. Coverity Reports installation modes .......................................................................................... 24
1.7. Platform Updater ..................................................................................................................... 25
This part of the guide is for administrators who install Coverity Platform, the name of the tool that installs
and upgrades the following components:
• Coverity Connect
• Coverity Policy Manager
Upgrades
Upgrade procedures are described separately in the Coverity 2019.09 Upgrade Guide , which
not only provides steps to perform the upgrade, but also includes important upgrade notes on new
features that will affect your upgrade.
Platform Updater
The Platform Updater is a separate Coverity tool that updates minor versions of the embedded JRE
and embedded PostgreSQL database without reinstalling Coverity Connect. To update from one
major version to the next (for example, from Java 8 to 9) a standard upgrade process is needed.
Platform Updater downloads JRE and PostgreSQL binaries from a Coverity website, and then
installs them to a Coverity Connect instance. The updater application can download first and
then install later, in case the binaries need to be installed on an isolated instance inside a secure
network.
The Platform Updater is available in the Coverity Connect installation directory: <install_dir>/
bin/
• cov-platform-updater-linux64-[version].sh
• cov-platform-updater-win64-[version].exe
Note
For further information regarding Platform Updater, see Section 1.7, “Platform Updater ”.
1
Installing Coverity Platform components
1.1. Installing Coverity Connect

This procedure is referred to as a Coverity Connect installation because all the Coverity Platform
components (including Coverity Policy Manager) are installed as part of Coverity Connect. In addition,
once Coverity Connect is running, IDE users can download and install Coverity Desktop plug-ins for
Eclipse, QNX Momentics, Wind River Workbench, IBM RTC, Visual Studio, IntelliJ, Android Studio,
and Gradle from the Downloads link in Coverity Connect. The link also provides access to the Coverity
Reports installer, which installs Coverity Integrity Report, Security Report, and Coverity MISRA Report.
Before installing to a production environment:
• You need to determine which database you intend to use. The Coverity Platform installer provides
the option of using a Coverity Connect database that is embedded in the installation package, or
connecting to a pre-existing external PostgreSQL database for Coverity Connect.
• It is important to understand deployment considerations and hardware recommendations described in

Chapter 5, Deployment planning and Chapter 6, Hardware recommendations and requirements.
• Coverity recommends that you or your database administrator choose and tune your file system
settings. Database-dependent application behavior relies on I/O (input/output), and the system I/
O can be further tuned for better performance. A good source for such information can be found in
PostgreSQL 9.0 High Performance authored by Gregory Smith and published by Packt Publishing.
Note that if you are simply performing a preliminary installation for trial purposes, you might opt to use the
embedded database and proceed with the installation without reference to the deployment considerations
described above. However, if you want to fully evaluate your installation, you should heed all preliminary
requirements and recommendations.
Also be sure that you have the following information prior to launching the installer:
• Desired installation directory.
• Location of your Coverity Connect license file.
• Desired ports for Coverity Connect communications.
• External PostgreSQL credentials (if not using the embedded database).
• Amount of available RAM (for embedded database performance).
To install Coverity Connect:
1. Verify that your installation environment meets Coverity software and platform requirements.
For details, see Section 7.1, “Coverity Connect and Coverity Policy Manager platforms”.
2. On the machine where you want to install Coverity Connect and other Coverity Platform components,
download the Coverity Platform installer file for your operating system.
3. If you do not plan to run Coverity Connect as a service, choose or create an operating system user
under which the Coverity Connect server software will run.
2
On Windows and Linux systems, this is the user who can start or stop Coverity Connect.
On Windows systems that run Coverity Connect as a service, the Administrator can start and stop
Coverity Connect.
4. Run the installer script or program for your operating system:
Linux, 64-bit
cov-platform-linux64-2019.09.sh
Windows, 64-bit
cov-platform-win64-2019.09.exe
Note
On Linux systems, you must not be logged in as root to install Coverity Platform.
For Windows, double-click the .exe program. It is recommended that you install Coverity Connect
with Windows Administrator privileges (installing Coverity Connect as a service requires it). To do so,
right click the installer and choose Run as Administrator.
For Linux, run the installer script in a Bourne shell, for example:
> ./cov-platform-linux64-2019.09.sh
The installer uses a text-based console mode or a graphical mode. The installation choices for
graphical and console modes are equivalent.
• To change the installer mode, see Section 1.2, “Coverity Platform installation modes”.
5. Complete the installation process:
a. Select and accept the license agreement for your region of the world.
b. Select the Fresh Installation option.
Note that if you intend to upgrade an existing Coverity Connect instance, you should follow one
of the upgrade procedures in the Coverity 2019.09 Upgrade Guide instead of using the steps
in this guide.
c. Enter the destination directory for the installation.
The destination directory should be on a local file system. In this documentation, the Coverity
Platform installation directory is referred to as <install_dir_cp>.
Note
For a fresh installation, you must use an empty directory. If an earlier version of Coverity
Connect is installed in the specified destination directory, the Coverity Platform installer
will treat the installation as an upgrade and attempt to install over the existing instance.
3
Note
Coverity Platform must be installed to a location where the user has full permissions.
Specifically, it is recommended that Coverity Platform not be installed into a location that is
only accessible by root.
d. Enter the location of the Coverity license file (license.dat).
Note
If your license is invalid, you will not be able to log into Coverity Connect. The installer will
not alert you if there is a problem with your license.
e. Choose the database type for Coverity Connect.
You can choose the embedded PostgreSQL database that is bundled within the installer (which
is recommended) or opt to connect to an external database that is hosted on a PostgreSQL
server. For supported PostgreSQL versions, see Section 7.1.1, “Coverity Connect software
requirements”.
Note that the external database option is only intended for experienced PostgreSQL DBAs. For
the installer settings for an external database, see Section 1.3.1, “Using an external PostgreSQL
database with Coverity Connect”.
f. If you chose the Embedded database option, enter the Coverity Connect database port and the
database location.
The TCP port that the embedded database server uses to listen for connections is only used for
localhost connections, so you should not need to configure your firewall. The default is 5432.
Choose the location for the embedded Coverity Connect database files. This location should
be on a local volume that has at least 2GB of free space. The default is <install_dir_cp>/
database.
g. If you chose the External database option, enter the following PostgreSQL configuration
parameters for the database you will use:
• PostgreSQL server name
• Database port
• Database name
• Database user
• Database password
If you have not already done so, you must ask your database administrator (DBA) to create
a database and user role for Coverity Connect. You (the user) must have privileges to create
4
and alter tables in the database. For more information, see Section 1.3, “Advanced installation
options”.
h. Select your Coverity Connect database performance tuning option.
Coverity Platform will warn you if your system does not meet the RAM requirements on your
system and you will not be able to select that tuning option.
To help with performance, you can choose from the following options:
1. Production - This tuning configuration is allowed to use all of the installed RAM on your
system.
2. Demo - Will run on a small computer and does not require the full 8GB of recommended
RAM. You should not use this option for any production system. This option should be used
for proof-of-concept or testing environments only.
Depending on your selection, the installer will suitably configure the JVM settings and
PostgreSQL configuration. For more information, See sections Section 8.2.1, “PostgreSQL
database tuning: embedded database” and Section 8.2.2, “JVM settings”.
Note
These deployment tunings do not affect database memory allocation when installed with
an external database; The PostgreSQL settings will not be modified. However, the JVM
settings are set whether an embedded or external database is used.
i. (Windows only) Choose whether or not to create Start Menu entries.
If you choose to have Start Menu entries created, you have the option to change the default
Start Menu folder, and you can choose whether or not to create shortcut entries for all users.
j. Choose and confirm the Coverity Connect administrator password.
This is the password for the Coverity Connect administrator (admin) account. Administrators
can use this account to log in with a web browser and configure users, create projects, and
manage other administrative settings.
k. (Windows only) Choose to run Coverity Platform as a service.
You must have Windows Administrator privileges to install and run Coverity Connect as a
service. The service runs as the built-in Windows account LocalService. You cannot change
this setting during the installation process.
l. Choose the host name configuration.
Choose from the host name of your machine, or the IP address.
m. Enter the HTTP port number.
5
This is the port that is used by the Coverity Connect server. Users connect to the HTTP port
to access Coverity Connect with a web browser and web services clients. If you are using a
firewall, make sure it is configured to allow incoming connections on this port. This is referred to
as the <http_port>. The default is 8080
If you want to configure Coverity Connect with a secure server, select Provide HTTPS service.
The HTTPS protocol requires an installed server certificate from a certificate authority. If you
choose this option, you must specify the HTTPS Port number. The default is 8443.
n. Configure the following ports:
• Commit port - The port used to send data from the build and analysis processes. If you are
using a firewall, make sure it is configured to allow incoming connections on this port. The
default is 9090.
• Control port - The Port used by the embedded application server for internal server
communication. The default is 8005.
6. If you changed any of the default ports, make a note of the port number(s) for later use, such as for
the cov-commit-defects --dataport command.
After the installation completes, a record of some of this information is also available in the following
files:
• <install_dir_cp>/config/cim.properties
• <install_dir_cp>/config/web.properties
• <install_dir_cp>/config/system.properties
• The Tomcat configuration files located at:
<install_dir_cp>/server/base/conf/server.xml
For example, see commitPort in cim.properties.
7. Check your installation:
a. Launch Coverity Connect by entering one of the following URLs into your web browser:
• http://<hostname>:<http_port>
• https://<hostname>:<https_port>
b. Sign into Coverity Connect with user name admin, and the administrator password that you
previously created.
If you are using HTTPS and you open Coverity Connect in a web browser before you have
enabled the server for SSL, you will receive an error message that you do not have the
6
correct certificate installed. After you have configured Coverity Connect to use the appropriate
certificates, you will be able to log into the system. For more information, see the "Configuring
Coverity Connect to use SSL" section in the Coverity Platform 2019.09 User and Administrator
Guide.
c. Review Section 1.4, “Post-installation notes”.
To uninstall Coverity Platform:
1. Go to <install_dir_cp>.
2. On Linux, run the uninstall script.
On Windows, run the uninstall.exe program, and follow the prompts. Note that you should
uninstall as an administrative user, particularly if you were running Coverity Connect as a service.
The uninstall script provides an option for removing user-supplied data. If you want to retain
these files for your own purposes, you should back them up before uninstalling Coverity Connect.
1.2. Coverity Platform installation modes

You can complete the series of installation steps using either a graphical or console (command-line)
interface. Alternatively, you can run the silent installer to complete the installation from the command line
in a single step.
1.2.1. Selecting an installation mode

On Linux-based systems, the console mode (with text-based prompts) is the default, and on Windows
systems graphical mode is the default. For both Coverity Platform and Coverity Analysis, you can use the
options describe below to select any of the other modes.
To specify an installer mode:
• Console mode: Use the command-line option -c for console mode.
• Graphical mode: Use the -g option for graphical mode.
• Silent mode: Use the -q option to run the silent (quiet) installer.
For example, to start the graphical installer on Linux:

> cov-platform-linux64-2019.09.sh -g
On Windows, when using the command prompt, you must precede the command with a start /wait
command. Additionally, if the executable filename contains spaces, you must include empty, double
quotes even if the filename is double-quoted:
> start /wait "" "<executable name>" -c
You can use the empty quotes even when the executable name does not contain spaces. For example:
> start /wait "" cov-platform-win64-2019.09.exe -c
7
1.2.2. Coverity Platform graphical installer

The Coverity Platform installer (see Section 1.2.1, “Selecting an installation mode”) provides options for
completing the most common Coverity Platform installation and upgrade use cases:
• Fresh install
• In-place upgrade
• Backup-and-restore upgrade
• Intermachine upgrade
• Upgrade preparation
For detailed instructions on all Coverity Connect upgrades, including external database upgrades, see
"Upgrading Coverity Connect" in the Coverity 2019.09 Upgrade Guide .
1.2.3. Coverity Connect silent installer

The Coverity Connect silent installer allows you to specify all of the installation configuration details on
the command line so you do not need to run the "step-through" process either through the command line
(-c) or the graphical (-g) installer modes.
To run the silent installer, specify the installation utility with the -q option, followed by the installation
parameters. The -q option and the installation parameters must all be on the same command line. The
following example installs a "production" Coverity Platform deployment with an embedded database.
./cov-platform-linux64-2018.06.sh -q \
--installation.dir ~/cov-platform-linux64-2018.06 \
--license.region=0 \
--license.agreement=agree \
--license.path=/tmp/license.dat \
--db.type=0 \
--db.embedded.performance=0 \
--admin.password=coverity \
--hostname=myhostname \
--http.port=14800 \
--commit.port=14801 \
--control.port=14802 \
--db.embedded.port=14803 \
If you are installing on Windows, use the -q -console options preceded by a start /wait
command. If the executable filename contains spaces, precede it with empty double quotes, even if the
filename itself is double-quoted, for example:
> start /wait "" "<my executable name>" -q -console
Note
You can include the empty double quotes whether or not the executable name contains spaces.
The silent installer accepts the following options. Note that not all of the options are required. For
example, you do not need to specify the options for an external (postgres) database if you are installing
8
Coverity Connect with an embedded database. If you use any of the following parameters, you should
provide specifically assigned values. Some values, if left blank, will accept the default value, but this
is not a recommended practice. For more information about the installation options, see Section 1.1,
“Installing Coverity Connect”.
Installer command line options
Note
Do not use the -V prefix with these options:
Option Description
-q Required. Enables the silent installer.
-console Required on Windows. Displays status messages
in the console from which you invoked the silent
installer.
General parameters
Parameter Description
--install.type=<0 | 1 | 2 | 3 | 4> Sets the installer to backup-and-restore mode.
For this option, the following values are available:
• 0 - Fresh install
• 1 - In-place upgrade
• 2 - Backup and restore
• 3 - Intermachine upgrade
• 4 - Upgrade preparation
Otherwise, the default value is set to 0.
--license.agreement=<agree> Required. Agree to the terms of the Coverity
product license.
--license.region=<0 | 1 | 2 | 3 | 4 Required. Specifies your region, used for
| 5 | 6> selecting the correct product license. The
following values (and representative region) are
available:
• 0 - Americas, Africa, and Israel
• 1 - Japan
• 2 - Taiwan
• 3 - China
• 4 - Republic of Korea
9
• 5 - International license (for any countries not
mentioned in 0-4)
• 6 - Evaluation Only. This installation is being

used solely for evaluation purposes, and is not
for production use
Fresh installation parameters

These parameters specify the options used for completing a fresh installation of Coverity Connect.
For a fresh installation, the --install.type setting value must be set to 0.
--accept.https=<true | false> Specifies that Coverity Connect should use SSL
(HTTPS) communication. The HTTPS protocol
requires an installed server certificate from a
certificate authority. The default value is false.
--admin.password=<password> Required. The administrator password that you
use to log into Coverity Connect upon installation.
--commit.port=<port> Recommended. Specifies the Coverity Connect
commit port. Default value is 9090.
--control.port=<port> Recommended. Specifies the port used by the
embedded application server for internal server
communication. Default value is 8005.
--db.type=<0 | 1> Specifies the type of database that is used with
the Coverity Connect application server. The
following option values are available:
• 0 - Embedded database parameters
This includes the --db.embedded.data and

--db.embedded.port options.
• 1 - External database parameters
This includes the following

options:--db.external.host,
--db.external.password,
--db.external.port, --
db.external.name, and
db.external.user.
Note
The external database must be created

before you run the installer.
10
For more information, see Section 1.3,
“Advanced installation options”.
Otherwise, the default value is 0. This specifies
that Coverity Connect will connect to an existing,
external PostgreSQL database.
--db.embedded.performance=<0 | 1> Selects the Coverity Connect database

performance tuning option. Based on your
installation type, choose one of the following
values:
• 0 - Production
• 1 - Demo
The default value is 0.

--hostname=<host-name> Required. Specifies the hostname of the Coverity
Connect server.
--http.port=<port> Recommended. Specifies the HTTP port number
for Coverity Connect. Default value is 8080.
--https.port=<port> Recommended. Specifies the HTTPS port
number for Coverity Connect. Default value is
8443. Valid if the --accept.https value is set
to true.
--installation.dir=<directory-path> Location to which Coverity Platform is installed.
This must be an absolute directory path.
--license.path=<path> Required. Specifies the full directory path of a
Coverity license.datfile.
--service.enable=<true | false> Specifies that Coverity Connect will be enabled
as a Windows service. This parameter is optional
and will not affect any installations on non-
Windows platforms. Default value is false.
In-place upgrade parameters

These parameters specify the options used for completing an in-place upgrade of an installed
instance of Coverity Connect. To upgrade a previously installed instance, the --install.type
setting value must be set to 1.
Prior to beginning an upgrade, see the Coverity 2019.09 Upgrade Guide for important upgrade
information and procedures.
--db.backup=<true | false> Default value is set to false. If set to true, this
option determines if the in-place upgrade process
11
creates a backup of the existing embedded
database.
--db.backup.dir=<directory-path> Required. Specifies the directory where the
backup database is stored. Valid if the --
db.backup option is set to true.
--db.backup.file= <filename> Required. File name of backup. Valid if the --
db.backup option is set to true.
performance tuning option. Choose values
depending on your installation type.
The following setting values are available:
• 0 - Production
• 1 - Restore
Otherwise, the default value is 0.

Backup-and-restore upgrade parameters

These parameters specify the options used for completing a backup-and-restore upgrade of an
installed instance of Coverity Connect. To backup and restore an upgrade, the --install.type
setting value must be set at 2.
certificate authority. Default value is taken from
the previous Coverity Connect instance that is
stored.
--backup.dir=<directory-path> Required. Specifies the directory where
the backup data is stored. Valid if the --
backup.automated option is set to false.
12

db.external.user.
Note


--backup.automated=<true | false> Initiates the automated backup and restore

process if set to true. Default value is true.
When set to false, the installer upgrades from a
previously created backup.
Note that for this option, the --back.dir option

must be specified.
commit port. Default value remains the same
from the previous Coverity Connect instance that
is stored.
communication. Default value remains the same
is stored.
• 0 - Production
13
• 1 - Restore

--existing.instance.dir=<directory- Required. The path of the existing Coverity
path> Connect.
Connect server.
for Coverity Connect. Default value remains
the same from the previous Coverity Connect
instance that is stored.
number for Coverity Connect. Default value
remains the same from the previous Coverity
Connect instance that is stored. Valid if the --
accept.https option is set to true.
Intermachine upgrade parameters

These parameters specify the options used for completing an intermachine upgrade of an installed
instance of Coverity Connect. This is similar to the backup-and-restore upgrade, but the upgraded
instance will be on a different machine than the original. To prepare your system for an intermachine
upgrade, the --install.type setting should be set to 3.
certificate authority. Default value is taken from
the previous Coverity Connect instance that is
stored.
--backup.dir=<directory-path> Required. Specifies the directory where the
backup data is stored.
commit port. Default value remains the same
14
is stored.
communication. Default value remains the same
is stored.
--db.backup.dir=<directory-path> Required. Determines if the in-place upgrade
process creates a backup of the existing
embedded database.
• 0 - Production
• 1 - Demo



db.external.user.
Note


15
Connect server.
for Coverity Connect. Default value remains
the same from the previous Coverity Connect
instance that is stored.
number for Coverity Connect. Default value
remains the same from the previous Coverity
Connect instance that is stored. Valid if the --
accept.https option is set to true.
Upgrade preparation parameters

These parameters specify the options used for completing an upgrade preparation of an installed
instance of Coverity Connect. This creates a backup for future use by the upgrade installer. To
prepare your system for an upgrade, the --install.type setting should be set to 4.
Prior to beginning an upgrade, see the Coverity 2019.09 Upgrade Guide for important upgrade
information and procedures.
--backup.destination=<directory- Required. Specifies the directory where you
path> want to store the backup data when using the
automated backup and restore process. You
can also use this setting to retrieve backed up
database information if you are upgrading (from a
previously created backup).
--existing.instance.dir=<directory- Required. The path of the existing Coverity
path> Connect.
Embedded database parameters

These options set the parameters for installing Coverity Connect with an embedded PostgreSQL
database. The installer will automatically install and configure the database.
16
--db.embedded.data=<path> Specifies the full path of the directory to which
the database files will be installed. If you do not
enter this option, the database directory defaults
to <install_dir_cp>/database.
-- Optional. Specifies the database port. Default
value remains the same from the previous
db.embedded.port=<database_port_number>
Coverity Connect instance that is stored.
However, for a fresh installation, the default value
is 5432.
External database parameters

These options set the parameters for installing Coverity Connect with an external PostgreSQL
database.
--db.external.host=<host_name> Required. Specifies the hostname of the external
PostgreSQL database.
--db.external.password=<database- Required. Specifies the administrative password
password> of the external PostgreSQL database.
--db.external.port=<port_number> Required. Specifies the external PostgreSQL
database port.
--db.external.name=<database-name> Required. Specifies the name of the external
PostgreSQL database.
--db.external.user=<admin-user-name> Required. Selects the name of the administrative
user that created the external PostgreSQL
database.
1.3. Advanced installation options

The following installation options are available.
1.3.1. Using an external PostgreSQL database with Coverity Connect

Coverity Connect can use a PostgreSQL database as an external database.
If you use an existing, external PostgreSQL database you are responsible for the database, including
implementing a database backup and recovery system.
Caution
This section is intended only for experienced PostgresSQL DBAs (database administrators).
Configuring PostgreSQL for Coverity Connect
You should be familiar with the following before performing this procedure.
17
Prerequisites for external PostgreSQL configuration
• A working installation of a supported PostgreSQL database: For supported PostgreSQL versions, see
Section 7.1.1, “Coverity Connect software requirements”.
• The ability to create a database role and a database.
• A database back-up and recovery system. Coverity Connect does not back up external databases.
To configure an external PostgreSQL database for Coverity Connect:
1. Create a new database and a role that has permissions to create, modify, and drop tables for
Coverity Connect. For example:
createdb -O <role name>...
The permissions allow the installer to create the database schema and to alter or drop tables when
you upgrade Coverity Connect.
It is required that you create the database with the following encoding settings:
--encoding UTF8 --locale C
These settings might not be available on some existing PostgreSQL installations, depending on the
version, the operating system, and the options used when initially creating the database cluster. For
more information consult the PostgreSQL documentation.
2. Record the following information prior to configuring Coverity Connect:
• PostgresSQL role name and password.
• Database name.
• PostgresSQL database server name.
• Port of the database listener.
3. Using the Coverity Connect installer, specify Connect to an existing PostgreSQL database, and
follow the prompts to complete the installation. The settings used by the installer for this configuration
are described in Table 1.1.
Table 1.1. External PostgresSQL Installer settings
Name Description Default

PostgreSQL server name Usually the host name where None
the PostgreSQL server runs.
Database port The TCP port on which 5432
the server is listening for
connections.
18
Name Description Default

Database name Name of the database that you None
previously created for use by
Coverity Connect.
Database user User name that owns the None
database name previously
specified.
Database password Password for previously None
specified user.
Run as service (Windows only) If you have Yes
Windows Administrator
privileges and want to run
Coverity Connect as a service.
The service runs as the
built-in Windows account
LocalService.
Launch web browser (Windows only) Opens a web Yes
browser on the URL to the
Coverity Connect server.
4. Start Coverity Connect.
5. Sign in to Coverity Connect by entering the following URL in your web browser's location bar:
http://hostname:<http_port>
When installing Coverity Connect with an external PostgreSQL database, you are not asked to
specify an administrator account password. Instead, sign in with user name admin, and password
coverity. For security reasons, after the initial sign-in, change the password for this account.
In the event of difficulties connecting to an external database, you might want to examine and edit
the property file (cim.properties) that controls the external database configuration. If you want to
enable SSL on your external database connection, you must edit this property file. See Section 1.3.2,
“Understanding database information in the cim.properties file”.
1.3.2. Understanding database information in the cim.properties file
To edit the <install_dir_cc>/config/cim.properties file:
1. Stop Coverity Connect:
Linux:
> cd <install_dir_cc>/bin
> ./cov-im-ctl stop
Windows:
19
Go to <install_dir_cc>\bin and double click the cov-stop-im program.
2. Check, and if necessary edit, the properties so that the following property values match:
• embeddedDatabase=false
This property is set to true when Coverity Connect uses an embedded database. However, after
you have installed Coverity Connect with an external database, you cannot just change this value
to true to change to an embedded database.
• maindb.name=<database_name>
• maindb.user=<ROLE_name>
• maindb.url = jdbc\:postgresql\://<database_server_name>\:<port_number>/
<database_name>
This property value takes the form of a JDBC URL.
To enable SSL on the external database connection, append ?ssl=true to this property value
(as shown in the following example).
For example:
#Mon Sep 14 11:13:39 PDT 2009
embeddedDatabase=false
maindb.name=jdoe_main
db.driver=org.postgresql.Driver
db.dialect=org.hibernate.dialect.PostgreSQLDialect
maindb.password=afy687
maindb.user=jdoe
maindb.url=jdbc\:postgresql\://t-postgres-03\:5432/jdoe_main?ssl=true
dir.log=/usr/local/jdoe/CIM/server/base/logs
commitPort=9090
dir.temp=/usr/local/jdoe/CIM/server/base/temp
You must restart Coverity Connect after you add this attribute.
1.3.2.1. Changing the limit on active connections to the database pool

You can add this property to cim.properties.
db.maxActiveConnections
Specifies the maximum number of active connections allowed to the database pool. The default is 50.
Example: db.maxActiveConnections=75
1.3.3. Optimizing JVM utilization of additional RAM in config/

system.properties
The application is started with the following JVM defaults.
20
For Production deployments (default):
-Xms=512m
-Xmx=<75% of the Total System Memory>
1.3.4. Changing the number of concurrent commits

These properties can be set in the cim.properties file.
commitPoolThreads
Specifies the number of concurrent threads to process commits off of the queue. Minimum 1.
Maximum 50. Default 5. To change this number, insert the following property:
commitPoolThreads=N (where N is the number of commits)
As commit performance and scale are affected by a number of factors (lines of code, number
of defects/issues, complexity of events, etc.) it is difficult to predict the concurrency load on the
application. While commitPoolThreads allows for greater levels of concurrency, it is possible to
subject the application to too much load.
When this occurs, there are errors in the $CIM_HOME/logs/cim.log that are indicative of this
issue. In some cases, these errors can be mitigated by increasing the heap memory allocation via the
-Xmx java_opts_post setting in the $CIM_HOME/config/system.properties file with the
provision that there is sufficient available system RAM. If not, the application load must be reduced
and/or limited by reducing commitPoolThreads value.
The errors are as follows:
1. java.lang.OutOfMemoryError: Java heap space - suggests that the maximum heap size
is insufficient for the JVM load.
2. java.lang.OutOfMemoryError: GC overhead limit exceeded - suggests that

the application is spending a significant amount of time performing garbage collection
instead of processing the application requests. This error can be disabled by appending
the -XX:-UseGCOverheadLimit to the java_opts_post in the $CIM_HOME/config/
system.properties file. This not recommended however as messages of this nature suggest
extreme memory pressure on the application.
commitWorkQueueCapacity
Specifies the number of commits that can wait in the queue. Minimum 15. Maximum 255. Default 80.
1.3.4.1. Concurrent commit requirements
Concurrent commits require additional RAM. Given projects with the following characteristics:
• Files analyzed: ~3000
• Total lines of code input to cov-analyze: ~3 million
21
• Functions analyzed: ~90,000
• Paths analyzed: ~7.5 million
• Defect occurrences found: ~4,000
The amount of memory required is as follows:
• 2 concurrent commits - 8Gb
• 5 concurrent commits - 16Gb (default commitPoolThreads value)
• 8 concurrent commits - 24Gb
Ideally, you should have 1 CPU core per concurrent commit.
1.4. Post-installation notes

After installing Coverity Platform, you should review the sections in this chapter along with the information
in Chapter 8, Coverity Connect system tuning, maintenance, and monitoring.
1.4.1. Important recommendations

After installing Coverity Connect, keep in mind these important recommendations:
• Do not move Coverity Connect from its installation location.
• Do not rename the Coverity Connect installation location.
• Do not start Coverity Connect from a different machine.
• Do not start Coverity Connect with a user other than the user who installed it.
• Do not use version numbers in the name of your installation directory. While using version numbers
is permitted, it could cause problems when you upgrade to a new version. When you upgrade, the
installation directory name is unmodified.
If you have to make these types of configuration changes, you should create a new installation, backup
your old system, and restore the backup into the new installation instance. See the Coverity 2019.09
Upgrade Guide .
1.4.2. Getting Coverity Platform licensing information

Coverity Connect and Coverity Platform licensing information is provided in the Help menu, in the About
option in Coverity Connect.
You can verify the type of license by clicking the About link in Coverity Connect and examining the
License Packaging field. To request information about the restrictions of your license, or to inquire about
upgrading your license, contact your Synopsys sales representative.
22
1.4.3. Installing multiple Coverity Connect licenses

You can update the Coverity Connect license by navigating to Configuration > System > Coverity
Connect License > Import the new file.
The new license file must be named in the following format:
license<name>.dat
Note
We recommend that you add the new license file before an old license file has expired to ensure
uninterrupted service when a license is renewed.
1.4.4. Stopping and starting Coverity Connect

To stop or start Coverity Connect:
• On Linux, go to <install_dir_cc>/bin and run the cov-im-ctl command.
The command accepts the maintenance, start, stop, or status options. For example, to get
status information:
> cd <install_dir_cc>/bin
> ./cov-im-ctl status
• On Windows, go to <install_dir_cc>\bin and run the cov-im-ctl.exe program.
When Coverity Connect is installed as a service, the cov-im-ctl.exe program is often unnecessary
because Coverity Connect starts and stops automatically when the system boots up or shuts down.
When Coverity Connect is installed as a service, any administrator can use this program.
When Coverity Connect is not installed as a service, only the user who installed Coverity Connect is
able to use this program to start or stop it.
Note
If you need to restart your external PostgreSQL database, see the PostgreSQL documentation.
1.4.5. Changing the Coverity Connect owner

In Unix, when installing Coverity Connect the current user becomes the owner of all unpacked files, and
is the only user who can execute command-line tools such as cov-im-ctl. The user name is also
recorded as the os_user in the config/system.properties file.
If the owner's account is removed, then a new owner must be assigned. Perform the following two actions
to change the Coverity Connect owner:
• At the command line, execute chown -R new_owner_username[:new_group]

<installation_dir>.
23
• Edit the config/system.properties file and change os_user to the new user name.
This has no effect on the database user name.
1.5. Installing Coverity Reports

Coverity Reports include the Integrity Report, Security Report, and MISRA Report. They are installed
separately from Coverity Connect. You can obtain installers from the Downloads page in Coverity
Connect.
1. In Help → Downloads, select the Coverity Reports installer that is appropriate for your operating
system.
2. Save the installer application to an appropriate folder on your system.
3. Launch the installer, and follow the instructions in the wizard.
1.6. Coverity Reports installation modes

in a single step.

This procedure is covered for all the Coverity product installers in Section 1.2.1, “Selecting an installation
mode”.
1.6.2. Coverity Reports silent installer

The Coverity Reports silent installer allows you to specify all of the installation configuration details on the
command line so you do not need to run the "step-through" process either through the command line (-c)
or the graphical (-g) installer modes.
parameters. The -q option and the installation parameters must all be on the same command
line. The following example installs Coverity Report version 2019.09 to the home/cov-reports-
linux64-2019.09 directory.
./cov-reports-linux64-2018.06.sh --installation.dir=~/cov-reports-linux64-2018.06 -q
Note
24
The silent installer accepts the following options. Note that not all of the options are required. If you use
any of the following parameters, you should provide specifically assigned values. Some values, if left
blank, will accept the default value, but this is not a recommended practice.
Note
Option Description
installer.
--installation.dir= <directory-path> Required. This option sets the location to which
the Coverity Reports product is installed. The
default value is <cwd>/Coverity/Coverity
Reports/.
1.7. Platform Updater

The Platform Updater updates the embedded JRE and embedded PostgreSQL database in Coverity
Connect without reinstalling Coverity Connect. Platform Updater will update minor versions. To update
from one major version to the next (for example, from Java 7 to 8), a standard upgrade process is needed
(see Coverity 2019.09 Upgrade Guide ).
Platform Updater downloads JRE and PostgreSQL binaries from a Coverity website, and then installs
them to a Coverity Connect instance. The updater application can download first and then install later, in
case the binaries need to be installed on an isolated instance inside a secure network.
If the JRE is updated, the Coverity Connect instance will be put into maintenance mode. If PostgreSQL is
updated, the Coverity Connect instance will be stopped and restarted.
The Platform Updater must be installed on the same machine as the Coverity Connect instance to
update, and must have the requisite write permissions.
If the JRE and PostgreSQL binaries were previously upgraded by using Platform Updater, then upgrading
Coverity Connect may install lower versions of the JRE and PostgreSQL binaries. In this event, run the
Platform Updater again.
The Platform Updater executable is found in the /bin directory of the Coverity Platforminstallation.
Launch the executable and follow the instructions below.
1.7.1. Using Platform Updater

The Platform Updater has three Installation Types: Download and Update, Download, or Update.
25
1.7.1.1. Download and Update
Use this procedure if the Coverity Connect instance is connected to the internet and is ready to be
updated now.
1. Launch the updater.
2. For Installation Type, select Download and Update.
3. Browse to the installation directory of the Coverity Connect instance.
4. The updater displays the JRE and PostgreSQL versions used by the Coverity Connect instance, and
the versions that are available for download from the Coverity server. Select Yes to continue to the
next step.
5. Select whether to update the JRE, PostgreSQL, or both.
6. Click Next, and continue until the updater completes.
1.7.1.2. Download
Use this procedure to download the binaries now, but install them at another time, or on a different
machine.
2. For Installation Type, select Download.
3. In the Download section, choose versions of JRE and PostgreSQL to download from the Coverity
server.
4. Select a download destination and click OK.
Note
Do not change the filename or the file itself in any way. Platform Updater will not be able to confirm
the integrity of the file.
1.7.1.3. Update
Update a Coverity Connect instance with binaries that were previously downloaded.
2. For Installation Type, select Update.
3. Enter the name of the Coverity Connect instance to update.
4. Select Update Java Runtime Environment and Update PostgreSQL, or both.
26
5. Select the location of the Coverity jar files that were previously downloaded.
Note
Coverity Connect is shut down if PostgreSQL is updated, and it is placed into Maintenance mode if
the JRE is updated.
1.7.2. Platform Updater in headless mode

The Platform Updater can be run in headless mode using the installer options listed in this section.

The following installer options are required:
Option Description
-q Enables the silent installer.
General parameters
--update.type=<0 | 1 | 2> Required. Sets which action the Platform Updater
should perform. You can select one of the
following values:
• 0 - Download and Update: downloads binaries

and installs them to a Coverity Connect
instance
• 1 - Downloads: downloads binaries to a

specified location, but does not install them
• 2 - Update: installs previously downloaded

binaries to a Coverity Connect instance
Download and Update parameters

The following options are used to customize the Download and Update parameters (where --
update.type=<0>).
Note
You cannot set both --update.jre and --update.pg to false.
--connect.instance.dir=<path-to- Required. Specifies which Coverity Connect
Coverity-Connect-instance> instance is updated.
27
--update.jre=<true | false> Updates the Coverity Connect JRE. If set to true,
the JRE is updated to the newest JRE available
for the installation. Default value is set to true.
--update.pg=<true | false> Updates the Coverity Connect Embedded
Postgres. Default value is set to true.
Download parameters
The following options are used to customize the Download parameters (where --
update.type=<1>).
Note
At least one --selected.jre or --selected.pg setting value must pass for the updater to
work.
--download.location=<directory-path> Required. Specifies the location to which the
binaries are downloaded.
--selected.jre=<JRE-version> Specifies the name of the JRE binary to
download. If left unspecified, then no JRE is
downloaded.
--selected.pg=<Postgres-version> Specifies the name of the Postgres binary to
download. If left unspecified, then no Postgres
binary is downloaded.
Update parameters
The following options are used to customize the Update parameters (where --update.type=<2>).
Note
At least one --location.jre or --location.pg setting value must pass for the updater to
work.
--connect.instance.dir=<path-to- Required. Specifies which Coverity Connect
Coverity-Connect-instance> instance is updated.
--location.jre=<directory-path> Specifies the location of the previously
downloaded JRE binary.
--location.pg=<directory-path> Specifies the location of the previously
downloaded Postgres binary.
The following example uses headless mode to download JRE and PostgreSQL binaries to the local
machine. To start the Platform Updater in headless mode, append the -q option. Note that the example
must be entered on a single line.
28
/bin/cov-platform-updater-linux64.sh -q \
--update.type=1 \
--download.location=/home/workstation/src/jasper.installer/download_dir \
--selected.jre=jre-1.8.0_31 \
--selected.pg=pgsql-9.6.2 \
The following example updates the local installation of Coverity Connect:

/bin/cov-platform-updater-linux64.sh -q \
--update.type=2 \
--location.jre=/home/workstation/src/jasper.installer/download_dir/jre-1.8.0_35-
linux64.jar \
--connect.instance.dir=/path/to/coverity_connect \
29
Chapter 2. Installing Coverity Analysis components
Table of Contents
2.1. Installing Coverity Analysis ....................................................................................................... 31
2.2. Coverity Analysis installation modes ......................................................................................... 34
2.3. Coverity Analysis license options ............................................................................................. 38
2.4. Using an archive file to install Coverity Analysis ........................................................................ 51
This part of the guide is for administrators who install Coverity Analysis.
Coverity Analysis provides tools that you use to analyze your code bases and programs. This document
guides you through the steps of running the Coverity Analysis installer.
Some of the analysis components that you can install include:
• Coverity Analysis – for analyses of compiled and interpreted code bases, including code used for Web
applications.
• Architecture Analysis – see the Architecture Analysis installation instructions for further information
about launching Architecture Analysis.
• Coverity Extend SDK
• Coverity Wizard – GUI-based configuration tool that is installed as part of Coverity Analysis.
• Coverity Desktop Analysis
• .NET Core SDKs
• Documentation:
• English version
• Japanese version
• Korean version
• Chinese version
Note
If you are upgrading an existing version of Coverity Analysis, see ???.
Note that certain Coverity Analysis components are only available for certain platforms. So, depending
on the platform on to which you are installing, you might only be able to access a subset of the analysis
tools. For details, see Section 7.2, “Coverity Analysis and Dynamic Analysis”.
30
Installing Coverity Analysis components
2.1. Installing Coverity Analysis

Prior to starting this procedure, you should have your license ready. For details, see Section 2.3,
“Coverity Analysis license options”. Prior to installing to a production environment, you should also make
sure that you understand the deployment considerations and hardware recommendations in Chapter 5,
Deployment planning.
In general, you should use the installation procedure described in this chapter. For rare cases where it is
not possible to do so, an alternative is described in Section 2.4, “Using an archive file to install Coverity
Analysis”.
To install Coverity Analysis:
1. Verify that your operating system, compiler versions, and the Coverity Analysis products that you
want to install on your platform are supported.
Depending on the Coverity Analysis components you intend to use, you will need to check one or
more of the following sections:
• Section 7.2, “Coverity Analysis and Dynamic Analysis”
• Section 7.3, “Coverity Test Advisor SCM and platform support”
• Section 7.2.3, “Supported platforms for Coverity Wizard”
• Section 7.4, “Architecture Analysis”
2. On the machine on which you want to install Coverity Analysis, download the installer file.
3. Run the installer script or program for your operating system.
The installer file name is similar to cov-analysis-<platform>-<version>.sh or .exe. For

example, the Linux 64-bit installer file is named cov-analysis-linux64-2019.09.sh, and you
might run it as follows:
> cov-analysis-linux64-2019.09.sh
For Windows systems, double-click the .exe program.
Depending on whether you are using Linux or Windows, the installer uses a text-based console
mode or a graphical mode. The installation choices for graphical and console modes are identical.
For guidance with changing the installer mode, see Section 1.2, “Coverity Platform installation
modes”.
4. Select and accept the End User Software License and Maintenance Agreement for your region of the
world.
5. Choose a destination directory for the Coverity Analysis components.
In this document, the Coverity Analysis installation directory is referred to as <install_dir_ca>.
31
6. Choose the Coverity Analysis components that you want to install.
Select from the following options:
• Coverity Static and Dynamic Analysis
Note that this option cannot be deselected.
• Extend SDK
• .NET Core SDKs
• Documentation
• English Documentation
• Japanese Documentation
• Korean Documentation
• Chinese Documentation
• Coverity Wizard
7. Choose your license file type:
• Coverity - Choose this option if you are using a license file with a .dat extension, for example
license.dat. To obtain or inquire about your license file from Coverity, send mail to
[email protected].
• FLEXnet - Choose this option if you are using a FLEXnet license file.
• Both - Choose this option if you have FLEXnet licensing for Coverity Analysis and want to use
Dynamic Analysis (Dynamic Analysis only uses Coverity licensing).
• Obtain from server - If you want the desktop analysis tool to automatically obtain a license file
from the Coverity Connect server. In order to use this option the administrator must first install the
analysis license file on the server. This is only valid when performing strictly Desktop Analysis, and
should not be used for Central Analysis servers.
Note
The Coverity Analysis installation process will not continue if you do not specify a license file or
license server location.
8. For Coverity licensing: Specify the location of your Coverity License file.
If you chose the Coverity or Both option for the license type, the installer prompts you to specify the
location of your license (.dat).
9. For FLEXnet licensing: Set up your FLEXnet license.config

32 file.
If you chose the FLEXnet or Both option for the license type, this step sets up the configuration file
that tells Coverity Analysis where the FLEXnet license server is. Choose from the following options:
1. Basic - Choose this option if you use a single license server. You will be prompted to enter the
license server hostname and license server port for your FLEXnet server.
2. Advanced - Choose this option if your license servers are a redundant triad. This option prompts
you to enter a comma-seperated list of three <port>@<hostname> values. For example:
28000@flex1,28001@flex2,28002@flex3
For more information about setting up FLEXnet licensing, see the Coverity Analysis 2019.09 User
and Administrator Guide (located in the <install_dir_ca>/doc directory).
3. Use an existing license.config file - Choose this option if you have an existing FLEXnet
configuration file. This option prompts you to specify the location of the configuration file.
10. On Windows, choose whether you want to create Start Menu folders and shortcuts.
11. Indicate whether to launch Coverity Wizard and the Coverity documentation from launching after the
installation is complete.
Note that cov-wizard is a GUI-based tool that you can use to run analyses. For Coverity Analysis
documentation, see Coverity Wizard 2019.09 User Guide and "Analyzing source code from the
command line" in Coverity Analysis 2019.09 User and Administrator Guide.
12. After the installation finishes, add <install_dir_ca>/bin to your PATH environment variable.
13. If you intend to install Architecture Analysis see Chapter 4, Installing Architecture Analysis.
14. [Optional] Check your installation directory.
Access to Coverity Analysis components in the following directories depends on the scope of your
license and the platform on which you are running Coverity Analysis (see Section 7.2, “Coverity
Analysis and Dynamic Analysis”).
• Coverity Analysis
Coverity Analysis tools and binaries are located at the top level installation directory. For example,
the Coverity Analysis commands are located in:
<install_dir_ca>/bin
All of the Coverity Analysis product documentation is accessible from the following locations:
• <install_dir_ca>/doc/en/index.html (English)
• <install_dir_ca>/doc/ja/index.html (Japanese). Please see the notice regarding the

availability of Japanese-language documentation in this file.
33
If your platform and license supports Dynamic Analysis, the tools and binaries are located in the
following directory:
<install_dir_ca>/dynamic-analysis
• For Coverity Analysis commands and the Coverity Wizard application (for example, cov-
wizard.exe on Windows):
<install_dir_ca>/bin
Note that Coverity Wizard starts automatically after installation of Coverity Coverity Analysis. For
information, see Using Coverity Wizard to Get Started with Coverity Analysis .
To uninstall Coverity Analysis:
1. Go to <install_dir_ca>.
2. On Linux, run the uninstall script.
On Windows, run the uninstall.exe program, and follow the prompts.
The uninstall script does not remove files that contain user-supplied data. To remove
user-supplied data, manually delete the installation directory after running the uninstall or
uninstall.exe script.
2.2. Coverity Analysis installation modes

in a single step.

This procedure is covered for both the Coverity Analysis and Coverity Platform installers in Section 1.2.1,
“Selecting an installation mode”.
2.2.2. Coverity Analysis silent installer

The Coverity Analysis silent installer allows you to specify all of the installation configuration details on
the command line so you do not need to run the "step-through" process either through the command line
(-c) or the graphical (-g) installer modes.
parameters. The -q option and the installation parameters must all be on the same command line.
The following example installs Coverity Analysis version 2019.09 to the home/cov-analysis-
linux64-2019.09 directory.
./cov-analysis-linux64-2018.06.sh -q \
--installation.dir=cov-analysis-linux64-2018.06 \
--license.region=0 \
34
--license.agreement=agree \
--license.type.choice=0 \
--license.cov.path=/tmp/license.dat \
Note
The silent installer accepts the following options. Note that not all of the options are required. If you use
any of the following parameters, you should provide specifically assigned values. Some values, if left
blank, will accept the default value, but this is not a recommended practice. For more information about
the installation options, see Chapter 2, Installing Coverity Analysis components.
Note
Option Description
installer.
--installation.dir=<directory-path> Required. This option sets the location to which
the Coverity Analysis product is installed. The
default value is <cwd>/cov-analysis-
<platform>-<version>.
General parameters
--desktop.link=<true | false> This option creates a desktop icon for Coverity
Analysis.This option is only valid on Windows.
Default value is false.
--license.agreement =<agree> Required. Confirms agreement to the terms of
the license.
--license.region=<0 | 1 | 2 | 3 | 4 Required. Specifies the region of the End User
| 5 | 6> License and Management Agreement (EULM).
It used to select the correct product license. The
available values (and representative region) are
as follows:
35
• 0 - Americas, Africa, and Israel
• 1 - Japan
• 2 - Taiwan
• 3 - China
• 4 - Republic of Korea
• 5 - International license (for any countries not

mentioned in 0-4)
• 6 - Evaluation Only. This installation is being

used solely for evaluation purposes, and is not
for production use
--license.type.choice=<0 | 1 | 2 | Specifies the type of license.
3>
• 0 - Coverity.dat license file.
• 1 - FLEXnet config.file license file.

"license.dat".
• 2 - Both Coverity.dat and FLEXnet

config.file license files.
• 3 - Obtain license file from server (in Desktop

mode)
Included component parameters

The following optional parameters specify which components will be included in the Coverity Analysis
installation. If unspecified, only Coverity Analysis and Dynamic Analysis will be installed.
--component.cov-wizard=<true | Installs the Coverity Wizard component. Default
false> value is true.
--component.dotnet-sdk=<true | Installs the .Net Core SDKs. This component
false> contains selected .NET Core SDKs that can be
used for buildless capture on C# .NET Core SDK
projects. By installing this component, you might
not need to install a .NET Core SDK in advance.
You need this component only if you intend to
use buildless capture to capture and analyze
C# projects. This option is valid only for 64-bit
36
--component.sdk=<true | false> Recommended. Installs the Coverity Extend
SDK. This option is valid only for platforms that
support Extend SDK. Default value is false.
--component.skip.documentation=<true Skips all documentation components. This option
| false> overrides all individual documentation component
options. Default value is false.
--component.en_doc=<true | false> Installs the English documentation
component. This option is ignored if --
component.skip.documentation=true.
Default value is true.
--component.ja_doc=<true | false> Installs the Japanese documentation
--component.ko_doc=<true | false> Installs the Korean documentation
--component.zh-cn_doc=<true | false> Installs the Chinese Simplified documentation
Coverity licensing parameters

The following parameters are optional configurations using the Coverity license. To use these
options, the --license.type.choice option must be set to 0 or 2.
--license.cov.path=<path> Required. Specifies the full directory path of a
Coverity license.dat file. This option is valid if
the --license.type.choice option is set to a
0 or 2.
FLEXnet licensing parameters

The following parameters are optional configurations using FLEXnet licensing. To use these options,
the --license.type.choice option must be set to 1 or 2.
--license.flex.choice=<0 | 1 | 2> Specifies your FLEXnet license server type. You
can set the value to one of the following:
• 0 - Basic, single license server
• 1 - Advanced, redundant triad of license

servers
37
• 2 - Existing license.config file.
Basic FLEXnet licensing parameters

Basic FLEXnet licensing parameters (where the --license.flex.choice value is 0) have the
following configurations available:
--license.flex.basic.host=<host- Specifies the host name of your FLEXnet
name> server. This option is required if you are
using a basic FLEXnet server or if the --
license.flex.choice option is set to 0.
--license.flex.basic.port=<port> Specifies the port number of your FLEXnet
server. This option is required if you are
using a basic FLEXnet server or if the --
Advanced FLEXnet licensing parameters

Advanced FLEXnet licensing parameters (where the --license.flex.choice value is 1) have
the following configurations available:
-- A FLEXnet server triad is specified
license.flex.advanced.triad=<triad> by a comma-separated list of three
port@host-name values. For example,
28000@flex1,28001@flex2,28002@flex3.
This option is required if the --

Existing FLEXnet licensing parameters

Existing FLEXnet licensing parameters (where the --license.flex.choice value is 2) have the
following configurations available:
--license.flex.config.path=<path> Specifies the full directory path to the
license.config file. The license.config
filename must be included at the end of the path.
This option is required if the --

2.3. Coverity Analysis license options

Coverity Analysis licenses have options that enable or disable functionality in Coverity Analysis and its
infrastructure. Any combination of the following software packages can be enabled:
38
• Quality analysis.
• Web application security analysis.
• Test Advisor analysis.
• Third Party Integration Toolkit usage.
• Dynamic Analysis analysis.
These options are provided through both of the Coverity Analysis licensing mechanisms:
• Coverity Analysis licenses: license.dat (available from

[email protected]).
• FLEXnet licenses: FLEXnet licenses provide floating-node features, including the counting of license
usage against a centrally maintained limit. See Section 2.1, “Installing Coverity Analysis” [p. 32] for
details.
Note
Coverity Analysis is supported on virtual machines (VMs) only if you use FlexNet licensing or a
default license that is not node-locked to a particular host machine.
Pre-6.5 licenses continue to be supported for backward compatibility. They do not have the options
mentioned above. When Coverity Analysis 6.5 sees a pre-6.5 license, it infers that quality analysis is
enabled and the other three options are disabled. Therefore, you don’t need a new license to run Coverity
Analysis 6.5 unless you want to use the three new features of 6.5.
Note that it is possible to reset your license after installing Coverity Analysis. This procedure is necessary
if you need to replace a trial license with a production license, if you need to update your license, or if
your current license file is invalid for some other reason.
2.3.1. Setting up a license.dat file

To set up default licensing:
1. Obtain a license file from Coverity by sending an e-mail to

[email protected].
2. Verify that the license file is named license.dat. If it is not, rename it to license.dat.
3. Copy the license file to the <install_dir>/bin directory.
Note
A missing license leads to a fatal No license found error when you attempt to analyze your
code.
On some Windows platforms, you might need to use administrative privileges when you copy
the Coverity Analysis license to <install_dir>/bin. Due to file virtualization in some
39
versions of Windows, it might look like license.dat is in <install_dir>/bin when it is

not.
Typically, you can set the administrative permission through an option in the right-click menu
of the executable for the command interpreter (for example, Cmd.exe or Cygwin) or Windows
Explorer.
2.3.2. Installing multiple Coverity Analysis licenses
You can update the Coverity Analysis license by placing multiple license files into the
$COVERITY_STATIC_ANALYSIS\bin folder.
The new license file must be named in the following format:
license<name>.dat
Note
We recommend that you add the new license file before an old license file has expired to ensure
uninterrupted service when a license is renewed.
2.3.3. Installing FLEXnet licenses
Coverity Analysis supports FLEXnet licensing. FLEXnet licensing is an alternative to the default licensing
process described in Section 2.3, “Coverity Analysis license options”.
Note
FlexLM software is now called FlexNet Publisher. For more information, go to:
http://www.flexerasoftware.com/products/flexnet-publisher.htm
http://www.globes.com/support/fnp_utilities_download.htm
The following table lists how the Coverity Analysis commands map to FLEXnet licensing features. This
information is helpful for troubleshooting purposes.
Table 2.1. Coverity commands mapped to FLEXnet licensing features
Coverity command FLEXnet licensing feature

cov-analyze analysis.master and analysis.worker
cov-commit-defects analysis.infrastructure
cov-format-errors analysis.infrastructure
cov-make-library analysis.master and analysis.worker
cov-configure analysis.infrastructure
There is one analysis.master for each analysis job.
40
There is one or more analysis.worker; one for each analysis worker. The number of parallel analysis
workers for cov-analyze is specified in the -j <number-of-workers> option. There is exactly one
worker each for cov-make-library.
To set up FLEXnet licensing for Coverity Analysis:
1. Verify that your platform is supported (see Chapter 7, Supported platforms).
2. Run the generate-flexnet-hostid command and send the results to

[email protected].
Coverity will send you, attached to an e-mail, a license file named coverity.lic.
The generate-flexnet-hostid command generates the MAC addresses of all NICs that will be
used for FLEXnet licensing.
Note
You must have the Linux standard base lsb package installed on your machine in order to run
generate-flexnet-hostid.
3. Rename the sample-license.config file to license.config and put it in the

<install_dir_sa>/bin directory.
Important
The <install_dir_sa>/bin/license.config file must exist.
If this file is empty, Coverity Analysis uses localhost for the default license server during the
analysis and committing of defects.
4. Start the license server manager from the <install_dir_sa>/bin directory by running the
following command:
> [nohup] lmgrd -c coverity.lic
The lmgrd command runs in the background. To run lmgrd in the foreground or to debug FLEXnet
license server problems on Windows, use the -z option. Avoid the -z option on UNIX or Linux
systems because the lmgrd daemon cannot be stopped with Ctrl-C.
To capture the output in a log file, use the -l <log-file> option.
Note
On some UNIX or Linux systems, if you do not use the nohup command, it is not possible to
log out of the license server from the shell where the lmgrd command ran. To avoid this, use
the nohup command on UNIX or Linux systems.
5. Edit the <install_dir_sa>/bin/license.config file to add your license server configuration

information using the following syntax:
license-server [<port1>]@<server1>[,[<port2>]@<server2> ... ]
41
Important
The license.config file that is used for FlexNet licensing needs to end with a newline
character - that is - end with a blank line. If it does not, cov-analyze will not recognize the
last line of the file.
Example:
license-server @localhost
Example:
license-server 28000@flex1,28001@flex1,28000@flex2
For information about troubleshooting FLEXnet licensing, see Troubleshooting for FLEXnet licensing .
For more information about the license server manager and FLEXnet licensing, see the License
Administration Guide, FLEXnet Publishing Licensing Toolkit 11.5 .
2.3.4. Troubleshooting for FLEXnet licensing

You might encounter the following common issues with licensing of Coverity Analysis. For more
information about the license server manager and FLEXnet licensing, see the License Administration
Guide, FLEXnet Publishing Licensing Toolkit 11.5 .
Note
FlexLM software is now called FlexNet Publisher. For more information, go to:
http://www.flexerasoftware.com/products/flexnet-publisher.htm
http://www.globes.com/support/fnp_utilities_download.htm
2.3.4.1. I get an lmutil not found error when I run generate-flexnet-hostid. .................... 43
2.3.4.2. A long message displays when I run the lmgrd command. .................................................. 43
2.3.4.3. The lmgrd command uses a different port number than the one in my license.config
file. ...................................................................................................................................... 43
2.3.4.4. The license server cannot verify my license. ....................................................................... 44
2.3.4.5. The license manager cannot initialize. ................................................................................ 44
2.3.4.6. The license file is different than the one that you expect. ..................................................... 45
2.3.4.7. The lmutil lmdown command cannot shut down the license server. ................................. 46
2.3.4.8. The lmutil lmdiag command returns a start date of 1-jan-1990. ...................................... 46
2.3.4.9. The clock difference is too large between the client and server systems. ............................... 46
2.3.4.10. The behavior of the following lmutil lmdown command query can cause confusion: ......... 47
2.3.4.11. The .flexlmrc file settings are not recognized. ............................................................... 47
2.3.4.12. The /usr/tmp/.flexlm file cannot be created. .............................................................. 47
2.3.4.13. The lmgrd -z option leaves lmgrd in the foreground on UNIX and Linux systems. ............ 47
2.3.4.14. The covlicd command exits unexpectedly. ..................................................................... 48
2.3.4.15. The lmutil lmhostid --help command does not display the -ether option. ............... 49
42
2.3.4.16. The message (covlicd) UNSUPPORTED:

"prevent.ccpp" (PORT_AT_HOST_PLUS ) displays. ........................................................ 49
2.3.4.17. License failure for systems configured to use IPv6. ............................................................ 49
2.3.4.18. cov-analyze will not recognize the last line of the file. .................................................... 50
2.3.4.19. On Linux environments, the FLEXnet licensing does not work with Ethernet devices that
have the LAN port mapped to anything other than eth0. ........................................................ 50
2.3.4.1. I get an lmutil not found error when I run generate-flexnet-hostid.
Solution
You must have the Linux standard base lsb package installed on your machine.
2.3.4.2. A long message displays when I run the lmgrd command.
Solution
The following FLEXnet marketing message displays when you run the lmgrdcommand. Real
error messages often proceed or follow it. Make sure to scroll up to the top of your screen to
read any error messages that display. For the sake of brevity, this content is removed from the
remaining questions and solutions.
13:53:54 (lmgrd) -----------------------------------------------

13:53:54 (lmgrd) Please Note:
13:53:54 (lmgrd)
13:53:54 (lmgrd) This log is intended for debug purposes only.
13:53:54 (lmgrd) In order to capture accurate license
13:53:54 (lmgrd) usage data into an organized repository,
13:53:54 (lmgrd) please enable report logging. Use Macrovision's
13:53:54 (lmgrd) software license administration solution,
13:53:54 (lmgrd) FLEXnet Manager, to readily gain visibility
13:53:54 (lmgrd) into license usage data and to create
13:53:54 (lmgrd) insightful reports on critical information like
13:53:54 (lmgrd) license availability and usage. FLEXnet Manager
13:53:54 (lmgrd) can be fully automated to run these reports on
13:53:54 (lmgrd) schedule and can be used to track license
13:53:54 (lmgrd) servers and usage across a heterogeneous
13:53:54 (lmgrd) network of servers including Windows NT, Linux
13:53:54 (lmgrd) and UNIX. Contact Macrovision at
13:53:54 (lmgrd) www.macrovision.com for more details on how to
13:53:54 (lmgrd) obtain an evaluation copy of FLEXnet Manager
13:53:54 (lmgrd) for your enterprise.
13:53:54 (lmgrd)
13:53:54 (lmgrd) -----------------------------------------------
2.3.4.3. The lmgrd command uses a different port number than the one in my license.config file.
Solution
If you provide a port number in the license.config file, use the port number of lmgrd. In the
following example, lmgrd uses port 27000 and covlicd (the Coverity vendor daemon) uses
port 60185. Use the lmgrd port in the license.config file.
$ ./lmgrd -c coverity.lic
43
13:53:54 (lmgrd) -----------------------------------------------

...
13:53:54 (lmgrd) -----------------------------------------------
13:53:54 (lmgrd) FLEXnet Licensing (v11.5.0.0 build 56285 amd64_re3) started on
bl-1-4 (linux) (4/3/2008)
13:53:54 (lmgrd) Copyright (c) 1988-2007 Macrovision Europe Ltd. and/or
Macrovision Corporation. All Rights Reserved.
13:53:54 (lmgrd) US Patents 5,390,297 and 5,671,412.
13:53:54 (lmgrd) World Wide Web: http://www.macrovision.com
13:53:54 (lmgrd) License file(s): coverity.lic
13:53:54 (lmgrd) lmgrd tcp-port 27000
13:53:54 (lmgrd) Starting vendor daemons ...
13:53:54 (lmgrd) Started covlicd (internet tcp_port 60185 pid 32023)
13:53:54 (covlicd) FLEXnet Licensing version v11.5.0.0 build 56285 amd64_re3
13:53:54 (covlicd) Server started on bl-1-4 for: prevent.platform
13:53:54 (covlicd) prevent.dotnet prevent.java prevent.ccpp
13:53:54 (covlicd) EXTERNAL FILTERS are OFF
13:53:54 (lmgrd) covlicd using TCP-port 60185
2.3.4.4. The license server cannot verify my license.
Solution
The license.config file might be incorrectly configured or empty. Verify that the license
server in the <install_dir_sa>/bin/license.config file correctly points to where the
lmgrd command is running.
The DNS server might be down. If the DNS server is down, use an IP address in the
license.config file instead of a hostname.
The license server might not be running. If it is not running, use the lmgrd command to start it.
The firewall on the license server might be blocking the lmgrd port. If so, make sure that the
server where the lmgrd command is running does not block ports 27000 through 27009 for
incoming TCP messages.
2.3.4.5. The license manager cannot initialize.
Solution
If you use the lmgrd command without the -c option, the command fails and displays an error
message that includes the text Cannot find license file at the top of the output on the
screen. Retry the lmgrd command using the -c option.
$ ./lmgrd coverity.lic
license manager: can't initialize: Cannot find license file.
The license files (or license server system network addresses) attempted are
listed below. Use LM_LICENSE_FILE to use a different license file,
or contact your software provider for a license file.
Filename: /usr/local/flexlm/licenses/license.dat
License path: /usr/local/flexlm/licenses/license.dat:
FLEXnet Licensing error:-1,359. System Error: 2 "No such file or directory"
For further information, refer to the FLEXnet Licensing documentation,
available at "www.macrovision.com".
14:04:49 (lmgrd) -----------------------------------------------
44
...
14:04:49 (lmgrd) -----------------------------------------------
14:04:49 (lmgrd) Using license file "/usr/local/flexlm/licenses/license.dat"
2.3.4.6. The license file is different than the one that you expect.
Solution
There are two reasons why the license file seems to be different than the one that you expect.
If the date on the license server is incorrect, the following type of error displays and likely causes
confusion. Change the date on the license server to today's date.
21:04:27 (lmgrd) -----------------------------------------------

...
21:04:27 (lmgrd) -----------------------------------------------
21:04:27 (lmgrd) FLEXnet Licensing (v11.5.0.0 build 56285 i86_re3) started on
rh el3x86 (linux) (5/11/2007)
Macrovis ion Corporation. All Rights Reserved.
21:04:27 (covlicd) FLEXnet Licensing version v11.5.0.0 build 56285 i86_re3
21:04:27 (covlicd) Feature prevent.platform is not enabled yet, starts on
12-may -2008
21:04:27 (covlicd) Feature prevent.ccpp is not enabled yet, starts on
12-may-200 8
21:04:27 (covlicd) License server system started on rhel3x86
21:04:27 (covlicd) No features to serve, exiting
21:04:27 (covlicd) EXITING DUE TO SIGNAL 36 Exit reason 4
21:04:27 (lmgrd) covlicd exited with status 36 (No features to serve)
21:04:27 (lmgrd) covlicd daemon found no features. Please correct
21:04:27 (lmgrd) license file and re-start daemons.
21:04:27 (lmgrd)
21:04:27 (lmgrd) This may be due to the fact that you are using
21:04:27 (lmgrd) a different license file from the one you expect.
21:04:27 (lmgrd) Check to make sure that:
21:04:27 (lmgrd) coverity.lic
21:04:27 (lmgrd) is the license file you want to use.
If you created the license file coverity.lic by copying and pasting from a Windows machine,
the space character (ASCII 32) might be replaced with a 160 character (hex 0xA0). To resolve
this, replace all the 0xA0 characters in the license file with spaces. In this case, the following
message displays:
$ ./lmgrd -c coverity.lic
9:58:10 (lmgrd)
9:58:10 (lmgrd) -----------------------------------------------
...
9:58:10 (lmgrd) -----------------------------------------------
45
9:58:10 (lmgrd)
9:58:10 (lmgrd)
9:58:10 (lmgrd) FLEXnet Licensing (v11.5.0.0 build 56285 amd64_re3) started on
bl-1-4 (linux) (4/23/2008)
9:58:10 (covlicd) FLEXnet Licensing version v11.5.0.0 build 56285 amd64_re3
9:58:10 (covlicd) License server system started on bl-1-4
9:58:10 (covlicd) No features to serve, exiting
9:58:10 (lmgrd) covlicd exited with status 36 (No features to serve)
9:58:10 (lmgrd) covlicd daemon found no features. Please correct
9:58:10 (lmgrd) license file and re-start daemons.
9:58:10 (lmgrd)
9:58:10 (lmgrd) This may be due to the fact that you are using
9:58:10 (lmgrd) a different license file from the one you expect.
9:58:10 (lmgrd) Check to make sure that:
9:58:10 (lmgrd) coverity.lic
9:58:10 (lmgrd) is the license file you want to use.
2.3.4.7. The lmutil lmdown command cannot shut down the license server.
Solution
The license server is not running. The following message displays:
$ lmutil lmdown
lmutil - Copyright (c) 1989-2007 Macrovision Europe Ltd. and/or Macrovision
Corporation. All Rights Reserved.
Shutdown failed: Cannot connect to license server system. (-15,570:115
"Operation now in progress")
2.3.4.8. The lmutil lmdiag command returns a start date of 1-jan-1990.
Solution
This is bug OA-002429 from Acresso (FLEXnet). Although the start date is incorrect, the
lmutil lmdiag command works as expected.
$ lmutil lmdiag
"commit" v2008.03, vendor: covlicd
License server: localhost
floating license starts: 1-jan-1990, expires: 26-mar-2008
This license can be checked out
2.3.4.9. The clock difference is too large between the client and server systems.
Solution
46
If the time difference between the client and server systems is larger than two days, the cov-
analyze, cov-commit-defects, and cov-format-errors commands will not run because
they cannot verify the license.
2.3.4.10. The behavior of the following lmutil lmdown command query can cause confusion:
Are you sure (y/n)?
Solution
Any letter after y or Y is ignored. If the first letter is not y or Y, the following message displays:
"No server selected, exiting"
2.3.4.11. The .flexlmrc file settings are not recognized.
Solution
Coverity command-line utilities do not use the .flexlmrc file. Store license settings in the
<install_dir>/bin/license.config file.
2.3.4.12. The /usr/tmp/.flexlm file cannot be created.
Solution
To resolve this, run the license server from a supported platform and edit the
<install_dir_sa>/bin/license.config file to point to the correct location of the license
server. FLEXnet on Linux is supported on systems running Red Hat Enterprise Linux 3, Red Hat
Enterprise Linux 4, or Red Hat Enterprise Linux 5.
23:41:25 (lmgrd) -----------------------------------------------
...
23:41:25 (lmgrd) -----------------------------------------------
23:41:25 (lmgrd)
23:41:25 (lmgrd) The license server manager (lmgrd) running as root:
23:41:25 (lmgrd) This is a potential security problem
23:41:25 (lmgrd) and is not recommended.
23:41:25 (lmgrd) Can't make directory /usr/tmp/.flexlm, errno: 2(No such file
or directory)
23:41:25 (lmgrd) Can't make directory /usr/tmp/.flexlm, errno: 2(No such file
or directory)
23:41:25 (lmgrd) Can't open /usr/tmp/.flexlm/lmgrdl.29777, errno: 2
license manager: can't initialize:
For further information, refer to the FLEXnet Licensing End User Guide,
available at "www.macrovision.com".
23:41:25 (lmgrd) Can't remove statfile /usr/tmp/.flexlm/lmgrdl.29777: errno No
such file or directory
2.3.4.13. The lmgrd -z option leaves lmgrd in the foreground on UNIX and Linux systems.
Solution
If you used the lmgrd -z option on UNIX or Linux systems, Ctrl-C does not terminate the
license server. To terminate the license server, manually terminate all lmgrd and covlicd
processes.
47
2.3.4.14. The covlicd command exits unexpectedly.
Solution
If the lmgrd and covlicd commands run on an unsupported platform, the following error
message displays:
./lmgrd -c coverity.lic
18:20:04 (lmgrd) -----------------------------------------------
...
18:20:04 (lmgrd) -----------------------------------------------
18:20:04 (lmgrd)
18:20:04 (lmgrd)
18:20:04 (lmgrd) FLEXnet Licensing (v11.4.100.0 build 50818 i86_re3) started on
lee-linux (linux) (4/26/2008)
18:20:04 (lmgrd) Copyright (c) 1988-2007 Macrovision Europe Ltd. and/ or
18:20:04 (covlicd) FLEXnet Licensing version v11.5.0.0 build 56285
i86_re3
18:20:04 (covlicd) lmgrd version 11.4, covlicd version 11.5
coverity@lee-linux:~/prevent-linux-4.0.0.beta1/bin$ 18:20:04
(covlicd) Server started on lee-linux for: prevent.platform
18:20:04 (covlicd) prevent.ccpp
18:20:04 (lmgrd) covlicd exited with status 0 signal = 17
18:20:04 (lmgrd) Since this is an unknown status, license server
18:20:04 (lmgrd) manager (lmgrd) will attempt to re-start the vendor daemon.
i86_re3
18:20:04 (lmgrd) REStarted covlicd (internet tcp_port 43652 pid 22155)
18:20:04 (covlicd) Server started on lee-linux for: prevent.platform
i86_re3
18:20:04 (covlicd) Server started on lee-linux for: prevent.platform
48

i86_re3
18:20:04 (covlicd) Cannot open lock file. errno=11 (/var/tmp/
lockcovlicd): Resource temporarily unavailable
18:20:04 (lmgrd) covlicd exited with status 41 (Exited because another server
was running)
18:20:04 (lmgrd) MULTIPLE "covlicd" license server systems running.
18:20:04 (lmgrd) Please kill, and run lmreread
18:20:04 (lmgrd)
18:20:04 (lmgrd) This error probably results from either:
18:20:04 (lmgrd) 1. Another copy of the license server manager
(lmgrd) is running.
18:20:04 (lmgrd) 2. A prior license server manager (lmgrd) was
killed with "kill -9"
18:20:04 (lmgrd) (which would leave the vendor daemon running).
18:20:04 (lmgrd) To correct this, do a "ps -ax | grep covlicd"
18:20:04 (lmgrd) (or equivalent "ps" command)
18:20:04 (lmgrd) and kill the "covlicd" process.
Make sure that the platform, upon which the lmgrd and covlicd commands run, is supported
by Coverity.
2.3.4.15. The lmutil lmhostid --help command does not display the -ether option.
Solution
The lmutil lmhostid -ether command generates the MAC addresses of all NICs that are
used for FLEXnet licensing.
For more information about the lmutil lmhostid -ether option, see the lmhostid syntax
in the License Administration Guide, FLEXnet Publishing Licensing Toolkit 11.5 . The Ethernet
address term in the FLEXnet documentation is incorrect. An accurate term is MAC address.
2.3.4.16. The message (covlicd) UNSUPPORTED: "prevent.ccpp" (PORT_AT_HOST_PLUS )

displays.
Solution
The following message might display if a specified feature is not listed in the license file. The
message is benign; Coverity Analysis will attempt to use the "prevent.analysis" feature instead.
If neither feature is present in the FLEXnet license file, Coverity Analysis will not run.
(covlicd) UNSUPPORTED: "prevent.ccpp" (PORT_AT_HOST_PLUS )

<email_address>@<domain>.com
(License server system does not support this feature. (-18,327))
2.3.4.17. License failure for systems configured to use IPv6.
Solution
49
Systems configured to use IPv6, which is now standard for some Linux distributions, can have
problems using FlexNet licensing with either Coverity Analysis for C/C++ or Coverity Analysis for
Java. If the server pointed to in the license.config file is @localhost you might get one of
these errors:
For Coverity Analysis for C:
cov-analyze --dir 'data'

[FATAL] Licensing failure.
[FLEXlm] License server machine is down or not responding.
[FLEXlm] See the system adminstrator about starting the license server system,
or
[FLEXlm] make sure you're referring to the right host (see LM_LICENSE_FILE).
[FLEXlm] Feature: prevent.analysis
[FLEXlm] Hostname: localhost
[FLEXlm] License path: 27000@localhost:
For Coverity Analysis for Java:
cov-analyze --max-mem 1024 --dir data junit-4.1.jar --findsource src
Coverity Static Analyzer for Java

Version 5.0.0 (pj5.0dev-push-2255)
using Java 1.6.0_07 (Sun Microsystems Inc.)
License check failed.

Could not get FLEXnet License
[ERROR] Could not verify the license.
FlexlmException: Can't Connect to License Server (-15,3002) (Connection
refused)
If you get one of the preceding error messages, check that the license server is running with
lmutil lmdiag -c <license>. If it is running, try changing the license.config file to
use @127.0.0.1 instead of @localhost. Next, rerun cov-analyze.
2.3.4.18. cov-analyze will not recognize the last line of the file.
Solution
The license.config file that is used for FlexNet licensing needs to end with a newline
character - that is - end with a blank line. If it does not, cov-analyze will not recognize the last
line of the file. Leave a blank line at the end of the license.config file.
2.3.4.19. On Linux environments, the FLEXnet licensing does not work with Ethernet devices that have
the LAN port mapped to anything other than eth0.
Solution
The FLEXnet licensing manager (FLEXlm), expects to get the MAC address only from the eth0
device. If the licensing machine LAN port is mapped to eth1 or higher, it will not get the correct
MAC address. The solution is to map the LAN to eth0.
50
2.4. Using an archive file to install Coverity Analysis

Coverity recommends using the executable installers (.sh, .exe files described in Section 2.1, “Installing
Coverity Analysis”) instead of the archive installers (.tar.gz and .zip files, for example, cov-
analysis-aix-2019.09.tar.gz) because the executables set up user preferences that you will
need, while the archive files do not. Archive installers are provided only for the very rare cases in which
there is a problem with the executables. If you need a command line mechanism for automating the
installation when using executables, see Section 2.2.2, “Coverity Analysis silent installer”.
To install Coverity Analysis components using an archive file:
1. Verify that your operating system and compiler versions are supported.
For details, see Section 7.2, “Coverity Analysis and Dynamic Analysis”.
2. Verify that the archive installer has the MD5 checksum described in the Coverity Customer Center
(requires login).
You need to use the md5sum utility to calculate the MD5 hash.
3. On the machine where you intend to perform builds and analyses, decompress the contents of the
archive into an installation directory that is not the root directory and that does not have a space
character (" ") in the directory name.
This directory is your <install_dir>.
4. Set up licensing for Coverity Analysis.
For details, see Section 2.3, “Coverity Analysis license options”.
5. Add the <install_dir>/bin/ directory to your PATH environment variable.
Once your PATH is set correctly, running command such as cov-help --help should display the
help page for the command.
51
Chapter 3. Installing Coverity Desktop components
Table of Contents
3.1. Installing Coverity Desktop for Eclipse, Wind River Workbench, QNX Momentics, and IBM
RTC ............................................................................................................................................... 52
3.2. Installing Coverity Desktop for Microsoft Visual Studio ............................................................... 57
3.3. Installing Coverity Desktop for IntelliJ IDEA and Android Studio ................................................. 58
3.4. Installing Coverity Analysis for local analysis ............................................................................. 59
This part is for administrators who install Coverity Desktop for Eclipse, Microsoft Visual Studio, and
IntelliJ IDEA.
3.1. Installing Coverity Desktop for Eclipse, Wind River Workbench,

QNX Momentics, and IBM RTC
The Coverity Desktop product is available through the Coverity Connect Downloads page. From this
page, you can:
• Obtain an update site location for installation or upgrade.
• Download the Coverity Desktop product packages and install them from your local desktop.
• Download Static Analysis and the corresponding license file for local analysis, if available.
To access the download page, sign in to Coverity Connect and click Downloads from the help menu.
If you have difficulty signing in and cannot access the Downloads page, it might be because you do
not have the appropriate role permissions or user credentials. If this occurs, contact your system
administrator.
Installation software prerequisites (see IDE and Java Version Support for supported version numbers):
• Wind River WorkBench, QNX Momentics, IBM Rational® Team Concert™, or Eclipse
• Java Runtime Environment
• Eclipse C/C++ Development Tooling (CDT), only for the C/C++ analysis
• Eclipse Java Development Tools (JDT), only for the Java analysis
3.1.1. Installing Coverity Desktop with the update site
Through Coverity Connect you can set up an update site to install Coverity Desktop or upgrade Coverity
Desktop when the update site is updated with the new version.
1. Under the Coverity Connect Help menu, select Downloads.
2. Use the pull-down menu to select your IDE.
52
Installing Coverity Desktop components
3. Copy the URL associated with your IDE (Eclipse, QNX Momentics, Wind River, IBM RTC), or click
the copy link icon.
4. In the IDE, go to Help → Install New Software...
Note
For Wind River Workbench only, you must go to the Device Debug perspective to make sure
that the Install New Software... is present in the Help menu.
Additionally, do not use the Help → Install into Eclipse... option. This option does not install the
Coverity plug-in.
5. Click the Add... button.
6. In the Location/Work with field, enter the update site URL and click OK.
7. Select Coverity DesktopC/C++ Analysis and Java Analysis (Eclipse only).
• Coverity Desktop Java Analysis and C/C++ Analysis each allow you to view and triage Coverity
issues in your project through central analysis.
• Coverity Desktop Java Analysis allows you to run local analysis for Java Quality Defects and
Security Risks.
• Coverity Desktop C/C++ Analysis allows you to run local analysis for C/C++ Quality Defects.
8. Click Next and review the Coverity Product License Agreement.
Note
The installation step, "Calculating requirements and dependencies," can take a long time
if there are invalid or slow URLs in the Available Software Sites list. To solve this, remove
the offending URLs or uncheck the box labeled Contact all update sites during install to find
required software.
9. Select the I accept the terms of the license agreement radio button.
10. Click Finish.
Note
The installation process might take a long time to complete because Eclipse checks for
updates for all of the selected update sites installed on your environment. To speed up the
installation, you can go to Help → Software Updates → Available Software → Manage Sites.
Uncheck all of the update sites except for cov-desktop-eclipse-2019.09. When you
want to update other components, go to Manage Sites and select them again.
11. Click Restart Now to restart the IDE.
12. Set up your workspace preferences.
53
For information about configuring Coverity Desktop, see the Coverity Desktop online help. To access
the help, select Help → Coverity Help Center, then open Coverity 2019.09 for Eclipse, Wind River
Workbench, and QNX Momentics: User Guide.
3.1.2. Installing Coverity Desktop from your local desktop

1. Under the Coverity Connect Help menu, select Downloads.
2. Use the pull-down menu to select your IDE.
3. Download and extract your preferred package:
For Eclipse
cov-desktop-eclipse-2019.09.zip
For Workbench
cov-desktop-windriver-2019.09.zip
For QNX Momentics

cov-desktop-qnx-2019.09.zip
For IBM RTC

cov-desktop-ibmrtc-2019.09.zip
4. From the IDE, select Help → Install New Software.
Note
For Wind River Workbench, you must go to the Device Debug perspective to make sure that
the Install New Software... is present in the Help menu.
Additionally, do not use the Help → Install into Eclipse... option. This option does not install the
Coverity plug-in.
5. Click the Add... button.
6. Click Local and browse to your Coverity Desktop package directory:
• <CD_package_dir>/cov-desktop-eclipse-2019.09
• <CD_package_dir>/cov-desktop-windriver-2019.09
• <CD_package_dir>/cov-desktop-qnx-2019.09
• <CD_package_dir>/cov-desktop-ibmrtc-2019.09
7. Click OK for the Browse For Folder dialog.
8. Click OK for the Add Site dialog. In Eclipse 3.6, click OK for the Add Repository dialog.
9. Select Coverity DesktopC/C++ Analysis and Java Analysis (Eclipse only).
54
• Coverity Desktop Java Analysis and C/C++ Analysis each allow you to view and triage Coverity
issues in your project through central analysis.
• Coverity Desktop Java Analysis allows you to run local analysis for Java Quality Defects and
Security Risks.
• Coverity Desktop C/C++ Analysis allows you to run local analysis for C/C++ Quality Defects.
10. Click Next and review the Coverity Product License Agreement.
11. Select the I accept the terms of the license agreement radio button.
12. Click Finish.
Note
The installation process might take a long time to complete because Eclipse checks for
updates for all of the selected update sites installed on your environment. To speed up the
installation, you can go to Help → Software Updates → Available Software → Manage Sites.
Uncheck all of the update sites except for cov-desktop-eclipse-*. When you want to
update other components, go to Manage Sites and select them again.
13. Click Restart Now to restart the IDE.
14. Set up your workspace preferences.
For information about configuring Coverity Desktop, see the Coverity Desktop online help, or
Coverity 2019.09 for Eclipse, Wind River Workbench, and QNX Momentics: User Guide .
To access the help, select Help → Help Topics. In the Contents pane, select Coverity Desktop for
use with Eclipse.
3.1.3. Auto-configuring compilers for the QNX and WindRiver toolchains

For the QNX and WindRiver toolchains, it is convenient to automatically configure the compilers by using
coverity.conf.
In coverity.conf, you can add a add_compiler_configurations element to the settings

section.
For more information, see: Coverity Desktop Analysis 2019.09: User Guide
For QNX:
"add_compiler_configurations": [
{ "cov_configure_args": ["--template", "--compiler", "qcc", "--comptype", "qnxcc"] }
]
For WindRiver:
55
"add_compiler_configurations": [
{ "cov_configure_args": ["--template", "--compiler", "ccmips", "--comptype",
"gcc"]},
{ "cov_configure_args": ["--template", "--compiler", "ccpentium", "--comptype",
"gcc"]},
{ "cov_configure_args": ["--template", "--compiler", "ccppc", "--comptype", "gcc"]},
{ "cov_configure_args": ["--template", "--compiler", "c++arm", "--comptype", "g+
+"]},
{ "cov_configure_args": ["--template", "--compiler", "cpparm", "--comptype", "g+
+"]},
{ "cov_configure_args": ["--template", "--compiler", "g++arm", "--comptype", "g+
+"]},
{ "cov_configure_args": ["--template", "--compiler", "c++mips", "--comptype", "g+
+"]},
{ "cov_configure_args": ["--template", "--compiler", "cppmips", "--comptype", "g+
+"]},
{ "cov_configure_args": ["--template", "--compiler", "g++mips", "--comptype", "g+
+"]},
{ "cov_configure_args": ["--template", "--compiler", "c++pentium", "--comptype", "g+
+"]},
{ "cov_configure_args": ["--template", "--compiler", "cpppentium", "--comptype", "g+
+"]},
{ "cov_configure_args": ["--template", "--compiler", "g++pentium", "--comptype", "g+
+"]},
{ "cov_configure_args": ["--template", "--compiler", "c++ppc", "--comptype", "g+
+"]},
{ "cov_configure_args": ["--template", "--compiler", "cppppc", "--comptype", "g+
+"]},
{ "cov_configure_args": ["--template", "--compiler", "g++ppc", "--comptype", "g+
+"]},
{ "cov_configure_args": ["--template", "--compiler", "dcc", "--comptype", "dcc"]}
]
Note
If the user has a data-coverity folder in their workspace, the

"add_compiler_configurations" setting will not take effect. To correct this issue, delete the
data-coverity folder.
3.1.4. Uninstalling Coverity Desktop

This section describes the steps to remove Coverity Desktop from your IDE.
In Eclipse, Desktop C/C++ Analysis and Desktop Java Analysis are displayed as separate components
in the installed components window. If you want to re-install or upgrade one of them, you must uninstall
them both.
To remove Coverity Desktop:
1. In Eclipse, go to Help → About Eclipse.
In WorkBench, go to Help → About Wind River Workbench.
56
In QNX, go to Help → About QNX Momentics.
2. Click Installation Details.
3. Select Coverity Desktop Analysis (for C/C++, Java (for Eclipse), or both).
4. Click Uninstall.
5. Restart the IDE.
3.2. Installing Coverity Desktop for Microsoft Visual Studio

The Coverity Desktop plug-in is available through the Coverity Connect Downloads page. From this page,
you can download the Coverity Desktop product package and install them from your local desktop or use
the update URL through the Visual Studio Gallery feature.
administrator.
• Visual Studio
• You must have an instance of Coverity Connect to connect to in order to configure Coverity Desktop to
run analyses and commit results.
3.2.1. Installing and updating Coverity Desktop for Visual Studio using a gallery
You can use a private gallery in Visual Studio (by providing its location) to install Coverity Desktop. This
allows automatic updates for the Coverity Desktop plug-in from within Visual Studio, whenever a new
version becomes available on the Coverity Connect server.
To use this feature, complete the following steps:
1. From the Coverity Connect Help menu, select Downloads.
2. Select Visual Studio from the IDE drop-down and copy the generated Gallery link.
3. In Visual Studio, navigate to Tools → Options → Environment → Extensions and Updates.
4. Click the Add button, enter a name for the extension, and paste the copied Gallery link in the URL
field. Then click Apply to save.
5. Click OK to close the options window.
6. Navigate to Tools → Extensions and Updates → Online and select the name you chose for the
Gallery.
7. Click Download to download the latest version of the plug-in.
57
For information about adding a private gallery to Extensions and Updates in Visual Studio, see http://
msdn.microsoft.com/en-us/library/hh266746.aspx .
For more information about managing a private gallery by using registry settings, see http://
msdn.microsoft.com/en-us/library/hh266735.aspx .
Note
You can also install the Visual Studio plug-in from your local desktop by downloading and running
the Coverity.Desktop.vsix file from the Coverity Connect Help → Downloads menu.
3.3. Installing Coverity Desktop for IntelliJ IDEA and Android Studio
The Coverity Desktop plug-in is available through the Coverity Connect Downloads page. From this page,
you can download the Coverity Desktop product package and install it from your local desktop.
administrator.
• IntelliJ IDEA or Android Studio

• You must have an instance of Coverity Connect to connect to in order to configure Coverity Desktop to
run analyses and commit results.
3.3.1. Installing Coverity Desktop from your local desktop

2. Select your IDE (IntelliJ or Android Studio) from the IDE pull-down menu.
3. Copy the displayed Plug-in repository URL.
4. In the IDE, open the Settings dialog (Preferences on Mac) and navigate to the Plugins page.
5. Click the Browse repositories button.
6. Select Manage repositories under the repositories list.
7. Click the Add (+) button to add a plug-in repository.
8. Enter the repository URL (copied from Coverity Connect) into the Repository URL field, and click OK.
9. Click OK to get back to the Browse Repositories dialog.
10. Right-click on "cov-desktop-*" from the list of repositories, and select Download and Install.
11. Click Yes to download and install the Coverity Desktop plug-in.
58
12. Click Close then OK to close out of the Settings dialog.
13. Select Restart when prompted.
Note
You may encounter issues connecting to Coverity Connect when using an SSL connection. If you
experience any connection issues when installing the Coverity Desktop plug-in, you can instead
use the following steps to install:
2. Select your IDE (IntelliJ or Android Studio) from the IDE pull-down menu.
3. Click the link to "download the plug-in".
4. In the IDE, open the Settings dialog (Preferences on Mac) and navigate to the Plugins page.
5. Click "Install plugin from disk".
6. Navigate to the downloaded cov-desktop-intellij-2019.09.zip file and click 'OK'.
7. Click 'OK' to close out of the Settings screen, and restart when prompted.
3.4. Installing Coverity Analysis for local analysis

If the Coverity Connect system administrator has configured the Downloads page to include the Coverity
Analysis installer, you can download it (and optionally the license.dat license file) to your system to.
Coverity Analysis contains Coverity Analysis which is used to run a local analysis.
1. In the Downloads page, download the Coverity Analysis package (if available).
2. If available, download the license file.
3. Run the Coverity Analysis installer.
It is required that you provide the location of the license.dat file during installation.
Note
In the case where Coverity Analysis uses a FLEXnet license, you will find a license.config
file in <SA_install_dir>/bin.
4. When you configure Coverity Desktop for local analysis, you can point the configuration to your local
Coverity Analysis instance.
59
Chapter 4. Installing Architecture Analysis
Architecture Analysis is installed separately from Coverity Analysis.
To install Architecture Analysis:
1. Download the Architecture Analysis installer.
2. Run the installer to install Architecture Analysis.
3. For your operating system, locate one of the following files:
Table 4.1. Architecture Analysis executable files
Host OS File Description

cov-aa-build-check-cva- Contains Windows executable:
all-<version>.zip Build-check the CVA Developer
Desktop Application.
Deprecation Notice: Support

for this tool is deprecated as of
2019.09 and will be removed in a
future release.
cov-aa-build- Contains Windows (64-bit)
check-dotnet-win64- executable: Build-check the .Net
<version>.exe Developer Desktop Application.

future release.
Windows
cov-aa-build-eclipse- Contains C/C++ CVA-based
feature-<version>.zip Eclipse Architecture Analysis
plugin, which is used to show
Architecture Analysis information
in an Eclipse IDE for developers.

future release.
cov-aa-build-check-java- Contains Windows (64-bit)
all-<version>.zip executable: Build-check the Java
Developer Desktop Application.

60
Installing Architecture Analysis

future release.
cov-aa-build-cva-all- Architecture Analysis Build CVA.
<version>.zip
cov-aa-build-dotnet- Windows (64-bit): Architecture
win64-<version>.zip Analysis Build .Net.
cov-aa-build-java-all- Architecture Analysis Build Java.
<version>.zip
cov-aa-cva-win64- Executable for the C/C++
<version>.exe version of Architecture Analysis
for Windows (64-bit).
cov-aa-dotnet-win64- Executable for Architecture
<version>.exe Analysis for Windows Visual
Studio (64-bit).
cov-aa-java-intellij15- Architecture Analysis plug-in for
a
plugin-<version>.zip the IntelliJ IDE version 15.

future release.
cov-aa-java-win64- Executable for the Java version
<version>.exe of Architecture Analysis for
Windows (64-bit).
cov-aa-server- Web application to run
<version>.zip Architecture Analysis as a
service.
cov-aa-build-check-cva- For Architecture Analysis
all-<version>.zip on Unix: Build-check CVA

future release.
Linux/Unix
cov-aa-build-check-java- For Architecture Analysis
all-<version>.zip on Unix: Build-check Java

future release.
61

<version>.zip

future release.
<version>.zip
cov-aa-cva-unix- Architecture Analysis CVA for
<version>.tar.gz Unix.
a

future release.
cov-aa-java-unix- Java version of Architecture
<version>.tar.gz Analysis for Unix.
<version>.zip Architecture Analysis.
cov-aa-build-check-cva- Includes macOS executable
all-<version>.zip for Architecture Analysis: Build-
check CVA Developer Desktop
Application.

macOS future release.
cov-aa-build-check-java- Includes macOS executable
all-<version>.zip for Architecture Analysis: Build-
check Java Developer Desktop
Application.

62

future release.
<version>.zip

future release.
<version>.zip
cov-aa-cva-macos- Executable for the C/C++
<version>.dmg version of Architecture Analysis
for macOS.
a

future release.
cov-aa-java-macos- Executable for the Java version
<version>.dmg of Architecture Analysis for
macOS.
<version>.zip Architecture Analysis.
a
See the official documentation for your IDE for information about installing plug-ins.
4. Install the package:
• If you are using one of the compressed files (.zip or .tar.gz), unpack the contents (usually to a
custom location).
• If you are using an executable .dmg or .dmg), run it.
5. After launching the application, point to a valid Coverity license (license.dat).
6. See the Architecture Analysis online help for product documentation.
63
Chapter 5. Deployment planning
Table of Contents
5.1. Deployment checklist ............................................................................................................... 64
5.2. How Coverity products integrate into a build system .................................................................. 66
5.3. Coverity Analysis deployment models ....................................................................................... 67
5.4. Coverity Connect deployment options ....................................................................................... 70
5.5. Other deployment models and features .................................................................................... 75
The following sections provide information that will help you make decisions about deployment for your
organization for the present -- with the goal of planning for future growth.
After you read this section, you will find it useful to read the Section 8.4, “Deployment scenarios ” so you
can see a practical implementation examples of Coverity tools.
5.1. Deployment checklist

The deployment checklist is a list of questions that helps you make decisions about how you will deploy
Coverity products (for example, which deployment models you will choose) and what hardware you will
choose.
When you are thinking about how you will deploy the tools, it is important to recognize that one of the
largest contributing factors to the performance of your system is based on system load. System load
consists of the following:
• Number of concurrent commits from Coverity Analysis to Coverity Connect - Commits represent the act
of sending and processing the Coverity Analysis results and defect data from the intermediate directory
to Coverity Connect. The number of and size of your commits can require a lot of hardware resources.
The number of commits also increases the size of the database that Coverity Connect uses to store
this information.
The basic criteria for commit load is the number of issue instances that are committed per unit of time.
This is determined by a number of factors, including the number of code bases, the size of each code
base, the number of branches and configurations per code base, and how many of the code bases will
be analyzed and how frequently.
• Number of concurrent users of Coverity Connect - The number of concurrent users on a Coverity
Connect system can affect the performance of the user interface.
• Number of concurrent Coverity Connect Web Services API calls - The Web Services API allows you
to write web applications that communicate with Coverity Connect. The number of concurrent Web
Service calls on a Coverity Connect system can affect the performance of the user interface.
• Number of concurrent desktop users - Desktop users fit into the desktop deployment model and as
such use both concurrent web services API calls and concurrent commits (although the size of the
commits tends to be much smaller than in a central build).
64
Deployment planning
Table 5.1. Deployment checklist

Deployment considerations Results/More information
notes
Questions regarding your organization's products
What platforms do you develop and build on? Consult the Supported platforms section of
this guide to determine operating systems,
versions, and required patches for Coverity
products.
How many products do you have in your The number of products can determine the
organization? number of streams you that you commit,
thereby impacting the commit load.
How many targets are typically built for each Targets are for a given product can determine
product? the number of streams you that you commit,
thereby impacting the commit load.
How many lines of code are in your product?
Questions regarding your organization's build process
When will a build be generated Are builds made on demand or integrated as
part of an automated process?
How frequently are builds initiated? The frequency of the builds in relation to the
analysis integration contributes to commit load,
and thus affects the way you plan for your
hardware deployment. For more information,
see Chapter 6, Hardware recommendations
and requirements.
What is the number of concurrent Coverity See Section 1.3.4, “Changing the number of
Analysis commits? concurrent commits”.
How is the build command invoked? Is it through a CI tool (such as Jenkins)? See
Section 5.5.2, “Coverity Jenkins plug-in”.
Do your developers develop on IDEs? See the deployment descriptions for the
desktop option.
Questions regarding your organization's development process
How many organizations or business units are
using Coverity products?
How many developers are there in each The number of concurrent users will impact
organization or business unit? the performance of your system, particularly
the Coverity Connect UI. Because of this, it is
important to have an accurate number of users.
Coverity has a list of maximum limits to help
ensure optimum performance. If the number of
users for your organization exceeds the limits,
you could consider implementing one Coverity
Connect deployment type over another.
65
Deployment planning
Deployment considerations Results/More information

notes
How are your developers distributed How developers in your organization distributed
geographically? geographically? Do you want developers
in other organizations to access a given
Coverity Connect instance? You could consider
implementing a Coverity Connect clustered
environment.
Do you have a "clean before check-in" policy? See the clean before check-in model.
Do you use a bug-tracking system? See Section 5.5.3, “Export issues”.
Do you have established standard back-up See Coverity Platform 2019.09 User and
procedures? Administrator Guide .
Do you have a system validation and See Section 8.3, “Monitoring and diagnosing
monitoring plan? Coverity Connect performance”.
Do you plan on using the Coverity deployment See Section 8.1.3, “The Coverity deployment
maturity model? maturity model”.
5.2. How Coverity products integrate into a build system

Before you make decisions about how to deploy Coverity products into your development environment,
it is important to understand how they can be integrated. This section shows how Coverity products are
integrated into a typical build environment.
It is important to recognize the various deployment options and recommendations so that you can
make decisions about the hardware to which you will install and implement Coverity components.
After you have identified how you want to deploy your Coverity system, you should use the hardware
recommendation chapter of this manual to set up your environment.
This section begins with a diagram and explanation of a basic build system. The subsequent deployment
figures in the section below build upon the basic to show how Coverity tools are integrated into a build
system.
Note
Note that for the diagrams that depict Coverity deployments, the dotted lines represent features or
tools that are optional.
The following image shows a high-level view of a basic build system:
66
Deployment planning
The build process flow is as follows:
1. The software developer makes changes or additions to a section of code.
2. When the developer is satisfied with her/his changes, the code is checked into a source control
management (SCM) system.
3. Build execution instructions (such as Makefiles) are invoked through a continuous integration (CI) tool
(such as Jenkins) upon receiving notification by the check-in process to the SCM.
4. The code is built at the scheduled interval. In this case, nightly.
5. Build success or failure is reported by the CI tool and notification of the result is sent to the
organization.
6. Meanwhile, the developer uses a bug tracking system to locate and manage possible bugs that are
found in the software.
7. The developer fixes the assigned bugs. The process repeats.
5.3. Coverity Analysis deployment models

The Coverity analysis tools are installed as part of the Coverity Analysis installation package and the goal
of these tools is to find issues in your code:
67
Deployment planning
Software organizations generally produce several products, and each product tends to consist of a
number of related code branches and targets. These branches and targets might be for the various
supported platforms, product versions, trunk and development branches. Coverity Analysis runs over
each code base to produce a snapshot of each code base. A snapshot consists of the results of running
Coverity Analysis once over a code base. The snapshot includes both the issue information and the
version of the source code in which the defects were found and is committed to Coverity Connect after
the analysis process is completed.
As your developers continue to modify their code bases, it is useful to provide them with on-going data
about the creation of new issues and the elimination of existing ones. Administrators can define streams
for each specific code base that they wish to analyze. A stream is a sequence of snapshots over a
specified code base. Each time Coverity Analysis runs, the analysis results are grouped with previous
results that are made up of the same code base and configuration. Streams capture issue information
and trends over time. For more information, see the Coverity Platform 2019.09 User and Administrator
Guide).
For specific implementation details (including how to configure compilers, integrate with the build, enable
checkers and so forth), see the Coverity Analysis 2019.09 User and Administrator Guide.
Note
Hardware considerations for the analysis tools are generally established by the needs of your
organization's build server (performance, size, and so forth.) However, there are some sizing
options to consider. For more information, see Section 6.2, “ Coverity Analysis hardware”.
5.3.1. Central build deployment model

Build engineers typically write scripts that automatically run Coverity Analysis on the source repository at
some scheduled interval (typically nightly). They can also allow developers to subscribe to automatically
68
Deployment planning
receive email notifications of new issues in their source files. Developers triage and annotate the defects
within Coverity Connect or Coverity Desktop. The central build model introduces the least amount of
change to the development process and provides a strict separation between developer and build
engineer tasks. A developer interacts with Coverity Analysis by adding or modifying source files in the
code repository and viewing issue results in Coverity Connect. A build engineer writes scripts to check
out the source from the repository, build it, initiate an analysis, and store the results in a Coverity Connect
database. Optionally, the build engineer can automatically notify developers of new issues in their source
code. The build engineer can integrate Coverity Analysis with the build process to automatically provide
Coverity Analysis consumers with fresh snapshots each morning or at another desired interval.
5.3.2. Desktop deployment model (local analysis)
This deployment model, which adds to the central Coverity Analysis build model, allows developers to
analyze code locally, and fix defects before checking their source code changes into the repository,
which means fewer issues reported in the central Coverity Connect database. Desktop developers also
have the ability to focus the analysis on a specific set of source files, which speeds up the analysis
considerably, and work with issues directly within their editor or IDE.
69
Deployment planning
It is suggested that the desktop model be deployed individually alongside a central build and analysis.
The central analysis should run periodically (perhaps nightly) in order to maintain current analysis data
for the full code base. Once this is in place, developers can use Desktop Analysis to get rapid, accurate
feedback from Coverity Analysis, drawing on summary data from the central build.
Coverity provides the Desktop Analysis tool, which can be used in one of three ways: from the command
line, with a text editor, or with Coverity Desktop, a plug-in to the Eclipse, Wind River WorkBench, QNX
Momentics, or Visual Studio IDEs. Coverity Desktop allows you to perform an analysis of your code,
then view and triage any issues within the IDE. For more information about Desktop Analysis, see the
Coverity Desktop Analysis 2019.09: User Guide .
The plugins for each IDE are designed to store various configuration settings in a file, coverity.conf.
The file can be stored in a directory that is part of source control, so that developers working on a
common code base will automatically receive the same settings in some parts of their IDE.
5.4. Coverity Connect deployment options

Coverity Connect receives the commit and issue data that was discovered by the Coverity analysis tools.
The discovered issues can then be assigned to your organization's developers. The developers, in turn,
can view the issues in the source code, classify the issues, and so forth. There are many more powerful
features in Coverity Connect; that you can implement to help you locate and fix issues, as well as tracking
and charting your organization's projects. For more information about Coverity Connect features, see the
Coverity Platform 2019.09 User and Administrator Guide .
Note
Coverity Analysis supports SNI (Server Name Indication) for all Coverity client tools. This means
that you can place Coverity Connect behind a reverse proxy that serves multiple domains.
70
Deployment planning
The are two primary methods in which to deploy Coverity Connect:
• As a stand-alone deployment.
• As a clustered environment.
Note that in the diagram above, the clustered environment is represented by the coordinator and
subscriber instances. At least one (stand alone or otherwise) Coverity Connect instance is required.
5.4.1. Coverity Connect stand-alone deployments

In this model, Coverity Connect is deployed as a standalone application. Users within your organization
will log in to and access a central instance of Coverity Connect. There can be multiple instances of
Coverity Connect in your organization, but issue data, classification states (triage), and trending metrics
are not shared among the individual instances (for information about deploying Coverity Connect as
a shared environment, see Section 5.4.2, “Coverity Connect clustered deployment model ”). Coverity
Connect comprises two main components:
• The Coverity Connect application server that hosts the application and its associated tools and
features.
• The database, which is a PostgreSQL database that contains all of the analysis and defect data, as
well as user and system components.
71
Deployment planning
In a standalone environment, Coverity Connect can be installed either with an embedded or external
PostgreSQL database:
Coverity Connect server with an embedded database. Installs the Coverity Connect application
server and the PostgreSQL database at the same time and on the same machine. This option is
generally used for its ease of use. It is the default option during installation and is useful for getting the
system up and running quickly. It might also be a good alternative for organizations that do not have a
dedicated Database Administrator.
Coverity Connect server with an external database. Allows you to install the Coverity Connect
application server in one location, and associate it with a separately installed PostgreSQL database. The
benefits to using an external database are:
• You can maintain and scale the PostgreSQL database separately. For example, you have finer control
of database system resources, such as kernel parameters and file system options.
• You can associate the Coverity Connect application server to an existing PostgreSQL database.
When you install Coverity Connect, you are prompted to choose a Production or Demo performance
tuning option. The installer will inform you if your current system settings are not properly configured. If
this occurs, you will have to adjust your system settings in order for Coverity Connect to run. For more
information, see Section 1.1, “Installing Coverity Connect”.
Both of the standalone deployment options are subject to system limits. So, it is recommended that you
determine the load on your system using the deployment checklist and then reference your results with
the Coverity Connect deployment limits table. If you think that your system might exceed theses limits,
you might to consider deploying Coverity Connect in a clustered environment.
72
Deployment planning
5.4.2. Coverity Connect clustered deployment model
The Coverity Connect clustered deployment model allows you to deploy clusters of Coverity Connect
instances on which centrally managed data is synchronized in an enterprise. Importantly, developer-
set triage states can be updated automatically across the cluster. For Coverity Connect to synchronize
data, it is necessary to set up one instance of Coverity Connect as the central Coordinator and to
configure other Coverity Connect instances into a cluster of Subscribers with which the Coordinator can
communicate.
When a developer updates an issue through the Coordinator or through a Subscriber, the update
propagates to other members of the cluster. In this way, the Coordinator is responsible for synchronizing
triage data updates across Coverity Connect Subscribers.
The benefits of using a clustered environment include the following:
• You can distribute the commit load over the subscribers or coordinator and you can choose specific
hardware for the clustered components (for example, clustered components that will accept larger
commit loads might have a different hardware configuration than those with lesser commits.)
73
Deployment planning
• The number of Coverity Connect users can be distributed across the environment so as to not limit
performance. For example, if the number of users on the system exceeds the numbers recommended
in the recommended maximum limits for a stand-alone system, you can set up a clustered environment
to offset the performance load.
• If you have users in separate geographic locations, you can set up subscribers for any number of
locales and still share issue information.
• Clustered components can be set with either embedded or external databases.
Note
If possible, the coordinator instance should act solely as coordinator, and have no projects,
streams, or snapshots configured. This will ensure that no individual project or stream information is
lost in the event of failure.
For more information about how the data is synchronized and to set up a clustered environment, see the
5.4.3. Recommended maximum limits in Coverity Connect

Coverity recommends the following boundary limits to ensure that Coverity Connect runs properly and
does not experience performance degradation. It is important to estimate for these limits, the results
may affect the way you deploy Coverity Connect and the hardware you choose for the deployment. To
estimate the limits in your organization, see the Section 5.1, “Deployment checklist”.
See the Glossary for basic definitions of the items described below.
You should not exceed any of the following:
Table 5.2. Coverity Connect maximum settings
System item Maximum number

Streams 1000
Projects 1000
Triage stores 1000 - This number should be much smaller than
the number of streams (1 is ideal).
Users 20,000
User Groups 100
Component maps 100
Components per component map 100
Defects per source file 100
Number of lines per source file 10,000
Database size 600 GB
Custom RBAC roles 20
74
Deployment planning
When working with the desktop deployment model, the following deployment memory requirements
should support only up to the listed number of users:
• 8GB (medium installer settings) - 100 users
• 16GB - 500 users
• 32GB - 1000 users
This guidance assumes that each Desktop Analysis client performs 20 operations per day and that there
are periodic commits against the Coverity Connect server which consist of a full analysis of the code
base. The same stream is compared (using the latest snapshot) against each individual cov-run-
desktop operation.
5.5. Other deployment models and features

The following diagram represents additional (and optimal) deployment considerations that can add value
to the developers and administrator of your system.
75
Deployment planning
The flow is as follows:
1. The developer fixes issues after being notified by Coverity Connect
2. The developer checks the fixes into the build.
3. Coverity analysis tools run on the code base.
4. Before the results are committed to Coverity Connect, the build administrator creates the Preview
Report to make sure that the code is clean before checking it in.
5. After the code is checked in, results of a passing or failing build is reported in Jenkins.
6. An issue report is exported in XML format and integrated into the organization's third party plug-in.
76
Deployment planning
5.5.1. Clean before check-in

The clean before check-in model is a way to verify that your code is "clean" before it is checked in to your
source control management (SCM) system. Before you commit the defects you can run a command line
executable to produce a Commit Preview Report. This report (in JSON format) shows the current state of
the issues on your system. Using this report, you can determine if you want to proceed with the commit.
The definition of "clean" is a policy that is determined by your organization; it is not necessarily defined
by Coverity. (Although, Coverity does offer the Deployment Maturity Model -- a Professional Services
program to bring your deployment to be "Coverity Clean." See Section 8.1.3, “The Coverity deployment
maturity model”.) So, these clean policies will most likely differ from organization to organization. For
example, your organization may only determine the code to be clean if there are no New issues were
found after a given analysis.
5.5.2. Coverity Jenkins plug-in

The Coverity plug-in for Jenkins makes it easy to add invocations of Coverity tools to an existing
automated build environment. The Jenkins plug-in adds value to the system by:
• Invoking the Coverity Analysis tools during your build
• Failing the build if defects are found matching certain criteria
• Reporting found defects after the build
To get the plug-in, go to https://wiki.jenkins-ci.org/display/JENKINS/Coverity+Plug-in/ .
5.5.3. Export issues

Coverity Connect allows you to export an Coverity Analysis issue into a file that can be imported into a
third-party bug tracking system. This is accomplished by enabling the Export button in the Triage pane
in the Coverity Connect user interface. To enable the Export button, you must create and install a utility
program to automatically handle the exported file.
For more information, see the Coverity Platform 2019.09 User and Administrator Guide .
77
Chapter 6. Hardware recommendations and requirements
Table of Contents
6.1. Coverity Connect hardware ...................................................................................................... 78
6.2. Coverity Analysis hardware ...................................................................................................... 79
6.1. Coverity Connect hardware

The following table lists the recommended hardware configurations for Coverity Platform deployments.
Note that these are recommendations and not necessarily requirements.
The hardware recommendations take into account the following Coverity Connect deployment options:
• Coverity Connect with an embedded database. This deployment includes the PostgreSQL database
and the Coverity Connect application installed on the same server and is a common Coverity Platform
deployment.
• Coverity Connect with an external database. In this deployment scenario, the Coverity Connect server
uses an external PostgreSQL database. For more information, see Section 1.3.1, “Using an external
PostgreSQL database with Coverity Connect”.
Table 6.1. Minimum hardware deployment recommendations
Server CPU RAM Storage size Storage device Notes

Embedded SSD: Enabling of
Intel Xeon E6 512GB+
database 32 GB TRIM recommended
26xx v3 Haswell
+ DDR3 SSD or HDD
External series or AMD 240GB+
1066Mhz HDD: 7200 rpm
database equivalent recommended
Note
• The minimum number of CPU cores is 8 with a minimum CPU speed of 2.0 Ghz.
• RAM should be 32 GB+ as a starting point. For existing Coverity Connect databases, it is
recommended that the amount of RAM be at least 25% of the database size. The database size
can be found in Coverity Connect by navigating to Help → About... → Database Size.
• Recommendations based on database size are a rough estimate.
• Performance depends on a variety of factors (commits, web access, web services traffic, etc.)
and can't be calculated by a formula. In addtion, the performance SLA might vary.
• Requirements vary over time as database growth and usage patterns change.
• You should monitor resource usage (Java and PostgreSQL processes) and modify performance
and resource allocations as necessary.
78
Hardware recommendations and requirements
• Here is an example configuration for a typical production performance host running Coverity
Connect with an embedded database as of 2018: 24 cores, 128GB RAM, 2TB HDD, 1TB SSD
• Virtualized environments are not recommended for optimal performance.
• If you deploy to a VM, ensure that the VM is at least on par with the recommended minimum
configuration.
• Troubleshooting performance problems on a VM is difficult because of the lack of visibility into

the VM host's resource usage. CPU cores and RAM can be limited on an underprovisioned VM
host.
• Sharing and available IOPS should be on par with the SSD/HDD.
• Storage virtualization is not recommended. Such systems might have problems achieving low-
latency I/O performance.
• Most RAID controllers do not support TRIM on RAID volumes.
• TRIM is required to maintain performance and longevity of the SSD.
• RAID configurations with parity (such as RAID 5) are sub-optimal for database I/O.
6.1.1. Database size guidelines
The amount of RAM available limits the size of the Coverity Connect database. It is recommended that
the amount of RAM be at least 25% of the database size.
In the minimum hardware configuration, there is a minimum of 32GB of RAM. If the JVM heap setting is
75% of system memory, or 24GB, then the database size can reach approximately 96GB before there
are any performance problems. You should periodically check the size of the Coverity Connect database
and consider provisioning more resources for the server if the database size increases to more than four
times the amount of available RAM.
The database size can be found in Coverity Connect by navigating to Help → About... → Database Size.
6.2. Coverity Analysis hardware

Coverity Analysis has certain minimum requirements for memory size. Though the speed of the analysis
can increase many times through the use CPU parallelism and extra memory, it is important to note the
following constraints:
• The speed of the analysis depends on the analysis configuration.
• There are points of rapidly diminishing return beyond which neither additional CPU parallelism nor
additional memory will increase the speed significantly.
79
6.2.1. Minimum requirements

When you start an analysis, Coverity Analysis will automatically compute how many analysis workers
to use based on the amount of memory the analysis requires and how much memory is available. It will
issue a warning if there is not enough memory.
You can use this section to understand memory requirements without starting an analysis.
CPU
There are no CPU minimums.
Memory
1.5 GiB [p. 81] minimum. However, running a JavaScript, TypeScript, PHP, Python, Swift, Web
application security, or Android application security analysis requires additional memory. See the
detailed requirements for the different types of analyses below.
The analysis might use more memory when it detects sufficient hardware.
Tuning the analysis with cov-analyze options such as --max-mem and --jobs affects
the required minimum. For information about parallel analyses, see Section 6.2.1.1, “Memory
requirements for parallel analyses”.
• When running only quality checkers (not including JavaScript, TypeScript, PHP, Python, or Swift
analysis):
1.0 GiB + (0.5 GiB * number of analysis workers)
For example, for an analysis that is not running any Web application security checkers and not
performing JavaScript, TypeScript, PHP, Python, or Swift analysis:
To run six analysis workers, you need 4 GiB (= 1 + (0.5 * 6)) of free memory. For eight
workers, you need 5 GiB (= 1 + (0.5 * 8)).
• When running Java, C#, and Visual Basic Web application security checkers or Android security
checkers (with or without the quality checkers), use the following formula to help determine the
minimum:
1.0 GiB + (0.5 GiB * number of analysis workers) + (3 GiB per million LOC)
Minimum memory requirements:
1.5GiB (only if result <= 1.5 GiB), else the result of this formula.
For example, to run six analysis workers when using a Web application security
checker on a 500,000 line code base (0.5 million LOC), you need 5.5 GiB (=
1.0 GiB + 0.5 GiB * 6 + 0.5 million LOC * 3 GiB = 1 GiB + 3
GiB + 1.5 GiB). However, if your result <= 1.5 GiB, you still need 1.5 GiB.
• JavaScript and TypeScript checkers:
Separate requirements for the file capture and analysis steps of the workflow apply.
80
• For JavaScript or TypeScript filesystem capture with cov-build: 2GiB
• Analysis of JavaScript or TypeScript with only quality checkers (not including Web application
security checkers such as DOM_XSS and SQLI):
• Analysis of JavaScript or TypeScript, including Web application security checkers such as

DOM_XSS and SQLI:
• PHP, Python, Ruby, and Swift checkers:
• For filesystem capture with cov-build: 1.5GiB
• For analysis:
Note
1 GiB is 2^30 bytes (approximately 1.074 GB).
6.2.1.1. Memory requirements for parallel analyses
The analysis can use hardware CPU parallelism (multiprocessor, multi-core, and multi-thread), assuming
adequate additional memory is available, but increases in speed depend on a number of factors:
• Whether you are running Web application security analyses or Android application security analyses:
Parallel analysis increases the speed of quality analysis only. It does not affect the speed of the Web
application security analysis or the Android application analysis.
• In general, the analysis runs faster with more threads, but the scalability of that speed increase
depends on the kind of analysis, the code language(s), and other properties of the code base. The
analysis of C code typically parallelizes best, followed by C++, followed by C# and Java quality
analyses, followed by Android security analyses and Web application security analyses. Android and
Web application security analyses are largely unparallelized.
Using available CPU parallelism requires sufficient memory. The number of analysis worker processes
can be up to the number of logical CPUs on the system (the number of processes that can run
simultaneously on the hardware), but each worker requires more memory to run. You can use the
following formula to estimate the minimum amount of memory that you are likely to need (noting that
more memory is safer, but less might work, especially for code bases smaller than 1 million LOC). For
detailed memory requirements, see Section 6.2.1, “Minimum requirements”.
6.2.2. Disks
Analysis of large codebases (MLoC) is especially sensitive to the random access speed of disks, though
extra memory can mitigate that issue somewhat by serving as OS disk buffers. Solid state disks (SSDs)
81
show a clear advantage over mechanical fixed disks ("hard drives"), and the IOPS rating of an SSD is the
best predictor of its performance with Coverity analysis (higher is better).
6.2.3. Operating system considerations

Coverity tools run notably slower on Windows than on other operating systems, such as Linux.
6.2.4. Shared machines

When the analysis runs simultaneously with other programs and makes a significant use of machine
resources, the primary concern is memory. With adequate physical memory for active processes and
adequate virtual memory (swap space) for inactive ones, sharing CPU time among other processes
does not pose problems. If adequate memory is unavailable, you can can reduce the memory usage by
configuring the analysis to use only part of available CPU parallelism.
You can think of the memory as "free physical memory" requirements, though when running the analysis
alone under a basic user environment, that is close enough to "total physical memory".
6.2.5. Virtual machines

The analysis is particularly sensitive to the overheads of running under a virtual machine. Better virtual
machine technologies significantly lower the observed overheads of worse technologies, but the fastest
analyses come from running analyses directly on the hardware.
82
Chapter 7. Supported platforms
Table of Contents
7.1. Coverity Connect and Coverity Policy Manager platforms .......................................................... 83
7.2. Coverity Analysis and Dynamic Analysis ................................................................................... 85
7.3. Coverity Test Advisor SCM and platform support .................................................................... 112
7.4. Architecture Analysis ............................................................................................................. 117
7.5. Coverity Desktop ................................................................................................................... 119
Coverity provides technical assistance explaining, configuring, debugging, and providing bug fixes and
work-arounds based on service level agreements on all supported platforms listed in this part. Refer to
the maintenance service terms for more details.
Important
Support for this version of Coverity will be discontinued 18 months after the next major release.
7.1. Coverity Connect and Coverity Policy Manager platforms

Coverity Connect and Coverity Policy Manager support the following server platforms and browsers.
Table 7.1. Coverity Connect and Coverity Policy Manager server platform support
Host OS Host OS version 32- or 64-bit Hardware Notes
architecture
Windows Windows 64-bit x86_64 Coverity requires
workstation a minimum service
releases: Windows pack of SP1 for
7 and higher Windows 7.
(except for
Windows 8.0) Deprecation
notice: Support
Windows server
for Windows 7
releases: Windows
is deprecated
Server 2012 or
as of version
higher
2017.07 and will be
Linux removed in a future
release.
Table 7.2. Coverity Connect and Coverity Policy Manager browser support
Browser Version Notes
Internet Explorer 11
Microsoft Edge Windows 10-supported versions
Firefox Mozilla-supported versions Coverity supports only the
Firefox and Chrome versions
83
Supported platforms
Browser Version Notes

Google Chrome Google-supported versions that are under maintenance,
and deprecates all end-of-life
versions.
Safari 8 and later Support for versions of Safari
that Apple no longer supports is
deprecated, and will be removed
from a future release.
The Coverity Desktop plug-ins for Eclipse, Microsoft Visual Studio, and other supported IDEs require the
same version for the Coverity Analysis and Coverity Platform installations for which Coverity Desktop is
configured to use. If you use Coverity Desktop, you must upgrade all Coverity products together to the
same version.
7.1.1. Coverity Connect software requirements

Coverity Connect requires the following software on the server-side operating system:
• On Windows:
• kernel32.dll
• powrprof.dll
• versionhelpers.h
• On Linux:
• glibc
• udev
Coverity Connect requires the following software on the client side:
• A supported browser. See Table 7.2, “Coverity Connect and Coverity Policy Manager browser support”.
• JavaScript enabled.
• Display resolution of at least 1024 x 768 pixels recommended.
The Coverity Connect server is bundled with the following software:
• Apache Tomcat 8.0
• PostgreSQL 10.9 (the embedded database)
• Sun/Oracle JRE 1.8.0_31
External PostgreSQL database:
84
Supported platforms
• In addition to the embedded database, Coverity Connect supports the following external database:
PostgreSQL 9.5.0–10.9
• An experienced PostgreSQL DBA is recommended for the external database configuration and use.
7.1.2. Compatibility with other Coverity product components

Coverity Connect interacts with several other Coverity product components, which include Coverity
Analysis, Dynamic Analysis, Test Advisor, and Coverity Desktop plug-ins. When installing multiple
Coverity components into the same environment, you must ensure that Coverity Analysis, Dynamic
Analysis, Test Advisor, and Coverity Desktop plug-ins are:
• All the same currently supported version.
• Not newer than Coverity Connect.
Note that Coverity Connect supports only the current version of Coverity Desktop plugins and the
previous two quarterly releases.
The following table illustrates the supported component version combinations:
Table 7.3. Coverity product components and version support
Coverity Connect Coverity Analysis, Dynamic Coverity Desktop

Analysis, Test Advisor
2019.09 2018.01 Unsupported
2018.03
2018.06
2018.09
2018.12
2019.03 2019.03
2019.06 2019.06
2019.09 2019.09
7.2. Coverity Analysis and Dynamic Analysis

7.2.1. Supported platforms for Coverity Analysis
This section describes Coverity Analysis support per language and per platform. The tables in this section
list all platforms and versions supported by Coverity Analysis. Specific language support is broken out per
platform.
Virtual machine (VM) implementations of the supported platforms are also supported if you use FlexNet
licensing or a default license that is not node-locked to a particular host machine (see the section
"Supported platforms for Extend SDK and FLEXnet Licensing" in this chapter for more information).
85
Supported platforms
The notes in the first table pertain to all platforms.
Table 7.4. Language support notes

Language Notes
C/C++ Compliance analysis is available with all C/C++
analysis platforms except AIX and NetBSD.
Java Coverity supports the execution of Web application
security analyses and SpotBugs analyses (through
Coverity Analysis for Java). All Java analyses
require Oracle Java SE Runtime Environment 8
(JRE-8) platform support.
Coverity does not support the Oracle JRockit JDK.
For information about invoking a particular Java

compiler with cov-build, see the table Java
supported compilers for Coverity Analysis in this
chapter.
JavaScript, TypeScript Coverity supports the execution of JSHint analyses
(through Coverity Analysis for JavaScript) on
platforms supported by Node.js 8.11.1.
Objective-C/Objective-C++ For details on the Clang compiler see the section
Supported Compilers: Coverity Analysis for C/C++.
Table 7.5. AIX: Coverity Analysis platform support

Platform version C/C++ Notes
AIX 7.1 on PowerPC ✓ Only manually integrated build
capture is supported because
the cov-build command is not
available, and it is necessary
to run cov-analyze on a fully
supported platform. For details,
see the references to AIX in the
Coverity Analysis 2018.09 User
and Administrator Guide.
Table 7.6. FreeBSD: Coverity Analysis platform support

Platform version C/C++ analysis Notes
FreeBSD 8.4 (32-bit) on i386 ✓ Deprecation Notice: Support for
(x86) FreeBSD 8.4 is deprecated as of
FreeBSD 8.4 (64-bit) on amd64 2019.09 and will be removed in a
(x86_64) future release.
FreeBSD 11.1 (32-bit) on i386 Deprecation Notice: Support for

(x86) FreeBSD 11.1 is deprecated as of
86
Supported platforms

FreeBSD 11.1 (64-bit) on amd64 2019.09 and will be removed in a
(x86_64) future release.
FreeBSD 11.2 (32-bit) on i386
(x86)
FreeBSD 11.2 (64-bit) on amd64
(x86_64)
FreeBSD 12.0 (32-bit) on i386
(x86)
FreeBSD 12.0 (64-bit) on amd64
(x86_64)
Table 7.7. Linux: Coverity Analysis platform support
Platform C/C++ Go Java JavaScript, Objective- Fortran Notes

version analysis analysis analysis PHP, C/C++ analysis
Python, analysis
Ruby,
Scala,
TypeScript
analysis
Linux ✓ ✓
Kernel
2.6.32+
(32-bit) with
glibc 2.14–
2.27 (32-
bit) on x86
Linux ✓ ✓ ✓ ✓
Kernel
2.6.32+
(64-bit)
with glibc
2.14–2.27
(64-bit) on
x86_64
87
Supported platforms
Table 7.8. macOS: Coverity Analysis platform support

Platform C/C++ C# Go Java JavaScript,Objective- Swift Notes
version analysis analysis analysis analysis PHP, C/C++ analysis
Python, analysis
Ruby,
Scala,
TypeScript
analysis
macOS ✓ ✓ ✓ ✓ ✓ ✓ Deprecation
10.12 Notice:
Support
for
macOS
10.12 is
deprecated
as of
2019.03
and will be
removed
in a future
release.
macOS ✓ C#
10.13 support
macOS on macOS
10.14 is limited
to Unity
2018.3
projects
using
the Unity
Roslyn
compiler.
Table 7.9. NetBSD: Coverity Analysis platform support

NetBSD 7.0 32-bit on x86 ✓ NetBSD 32-bit support covers the
NetBSD 7.0 64-bit on x86_64 x86 processor only, not other 32-
bit processors.
NetBSD 7.1 32-bit on x86
NetBSD 7.1 64-bit on x86_64 Because of a NetBSD bug, on 64-
bit versions of NetBSD, Coverity
NetBSD 7.2 32-bit on x86 Analysis will fail while attempting
NetBSD 7.2 64-bit on x86_64 to capture any 32-bit build (or
mixed 32 and 64-bit build). To
NetBSD 8.0 32-bit on x86
avoid this, you must bypass
NetBSD 8.0 64-bit on x86_64
88
Supported platforms

cov-build and use cov-translate
directly.
Table 7.10. Solaris: Coverity Analysis platform support

Solaris 10 and 11 (64-bit) on ✓ Deprecation notice: Support for
x86_64 Solaris 10 has been deprecated
Solaris 10 and 11 (64-bit) on as of 2019.03 and will be
SPARC removed in a future release.
Table 7.11. Windows: Coverity Analysis platform support

Platform C/C++ Go Java C#/Visual JavaScript,Objective- Fortran Notes
version analysis analysis analysis Basic PHP, C/C++ analysis
analysis Python, analysis
Ruby,
Scala,
TypeScript
analysis
Windows ✓ ✓ Coverity
32-bit requires
workstation the SP1
releases service
Windows pack for
7 and later Windows
(except for 7.
Windows
8.0) Deprecation
Notice:
Support
for
Windows
7 is
deprecated
as of
2019.09
and will be
removed
in a future
release.
Windows
32-bit
server
releases
Windows
89
Supported platforms

Ruby,
Scala,
TypeScript
analysis
Server
2012 and
later
Windows ✓ ✓ ✓ ✓ ✓ Coverity
64-bit requires
workstation the SP1
releases service
Windows pack for
7 and later Windows
(except for 7.
Windows
8.0) Coverity
Analysis
for C#
and Visual
Basic
supports
analysis of
programs
compiled
by the
Visual C#
compiler
(csc.exe)
and Visual
Basic
compiler
(vbc.exe)
from .NET
Framework
versions
3.5 SP1
and 4.5.2–
4.7.
Deprecation
Notice:
Support
for
Windows
90
Supported platforms

Ruby,
Scala,
TypeScript
analysis
7 is
deprecated
as of
2019.09
and will be
removed
in a future
release.
Windows Coverity
64-bit Analysis
server for C#
releases and Visual
Windows Basic
Server supports
2012 and analysis of
later programs
compiled
by the
Visual C#
compiler
(csc.exe)
and Visual
Basic
compiler
(vbc.exe)
from .NET
Framework
versions
3.5 SP1
and 4.5.2–
4.7.
7.2.2. Supported platforms for Extend SDK and FLEXnet Licensing
This section describes Extend SDK and FLEXnet Licensing support per platform. The following table lists
all platforms and versions on which Extend SDK and/or FLEXnet Licensing is supported.
Virtual machine (VM) implementations of the supported platforms are also supported if you use FlexNet
licensing or a default license that is not node-locked to a particular host machine.
91
Supported platforms
Table 7.12. Extend SDK and FLEXnet licensing platform support
OS Platform Extend SDK FLEXnet licensing Notes

FreeBSD 8.4 (32-bit) on i386 ✓ Deprecation
(x86) Notice: Support for
8.4 (64-bit) on FreeBSD 8.4 and
amd64 (x86_64) 11.1 is deprecated
as of 2019.09 and
11.1 (32-bit) on will be removed in a
i386 (x86) future release.
11.1 (64-bit) on
amd64 (x86_64)
11.2 (32-bit) on
i386 (x86)
11.2 (64-bit) on
amd64 (x86_64)
12.0 (32-bit) on
i386 (x86)
12.0 (64-bit) on
amd64 (x86_64)
Linux Linux Kernel ✓ ✓
2.6.32+ (32-bit) with
glibc 2.142.27 (32-
bit) on x86
Linux Kernel
2.6.32+ (64-bit) with
glibc 2.142.27 (64-
bit) on x86_64
macOS 10.12 ✓ Deprecation Notice:
Support for macOS
10.12 is deprecated
as of 2019.03 and
will be removed in a
future release.
10.13
10.14
Solaris 10 and 11 (64-bit) ✓ ✓ Extend SDK
on x86_64 requires the
10 and 11 (64-bit) libiconv library, and
on SPARC you must configure
the system dynamic
loader (ld.so.1) to
locate it.
92
Supported platforms
OS Platform Extend SDK FLEXnet licensing Notes

Windows Windows 32- ✓ ✓ Coverity requires
bit workstation the SP1 service
releases Windows pack for Windows 7
7 and later (except
for Windows 8.0)
Windows 32-bit
server releases
Windows Server
2012+
Windows 64- Coverity requires
bit workstation the SP1 service
releases Windows pack for Windows 7
7 and later (except
for Windows 8.0)
Windows 64-bit
server releases
Windows Server
2012+
7.2.3. Supported platforms for Coverity Wizard

Coverity Wizard supports the following platforms:
Table 7.13. Coverity Wizard supported platforms

Host OS Version Notes
Windows 64-bit Windows workstation Coverity requires a minimum
releases: 7 and later (except for service pack of SP1 for Windows
Windows 8.0) 7.
64-bit Windows server releases:
Deprecation Notice: Support for
Windows Server 2012 and higher
Windows 7 is deprecated as of
future release.
Linux 64-bit Linux with glibc 2.14 or
higher
macOS 10.12–10.14 Support for Mac OS X 10.11 has
been deprecated as of 2018.01.
Mac OS X and macOS can

access Coverity Wizard only
for use with Coverity Analysis.
Coverity Wizard for Test Advisor
is not supported on any Mac
platform.
93
Supported platforms
7.2.4. Supported frameworks for Coverity Analysis

Coverity Analysis explicitly supports the following frameworks, libraries, APIs, and other technologies
(referred to hereafter as simply frameworks). Coverity Analysis can successfully analyze most
frameworks, even if they are not explicitly supported. If your framework is not listed in the following table,
don't be overly concerned; just run an analysis and check your results.
Table 7.14. Frameworks supported by Coverity

Language Supported Frameworks
Java Android SDK
Apache Shiro
Axis
DWR
Enterprise Java Beans (EJBs)
GWT
Hibernate
iBatis
Java Persistence API (JPA)
javax.websocket
JAX RS
JAX WS
JEE
JSF/Facelets
JSP and JSP Standard Tag Library (JSTL)
ReactiveX (RxJava, Reactor)
Restlet
Sprint boot
Spring framework
Struts
Terasoluna
Tiles
Vert.x
WSXmlRpc
C# ASP.NET ASMX Web Services
ASP.NET Core
ASP.NET Core MVCASP.NET Web API
ASP.NET MVC
94
Supported platforms

ASP.NET Web Forms
Razor templates
WCF Services
JavaScript/TypeScript -------------------- Client-Side --------------------
Angular
AngularJS
Backbone
Bootstrap
Cordova
Ember
HTML5 DOM APIs / Ajax
JQuery
Mithril
React/preact
socket.io
Vue
-------------------- Server-Side --------------------

Angular server-side rendering (Express and Hapi
engines)
Express
Fastify
Hapi
Koa
Mean.io
Node
Restify
SAP XS Classic and Advanced
Passport
React server-side rendering (next.js)
Vue server-side rendering
-------------------- Template Engines --------------------

Consolidate
95
Supported platforms

doT.js
EJS
Haml
Handlebars
Hogan
Jade
koa-views
Lodash (templating)
Marko
Mustache
Nunjucks
Pug
Swig
Twig
Underscore (templating)
Vision
-------------------- Major Libraries --------------------

Axios
Google Cloud APIs (Storage)
Mongoose / MongoDB
request
Sequelize
Underscore / Lodash
PHP Symphony
Python Django
Flask
Ruby Ruby on Rails
96
Supported platforms
7.2.5. Supported compilers: Coverity Analysis for C#
Table 7.15. Supported C# compilers for static analysis
Compiler Compiler version Language version Host OS Notes

Visual Studio 2010, 2012, 2013, Up to C# 7.3 Windows 64- Visual Studio
2015, 2017, 2019 bit workstation Express editions
.NET Core 2.0–2.2 releases Windows are not supported.
7 and later (except
for Windows 8.0) Coverity supports
analysis of
Windows 64-bit Windows RT
server releases applications.
Windows Server
2012 and later Coverity supports
capturing projects
Unity 2018.3 macOS
only with the Unity
Roslyn compiler.
Deprecation notice:
Support for Visual
Studio 2010 is
deprecated as of
2019.09 and will be
removed in a future
release.
Deprecation notice:
Support for Visual
Studio 2012 is
deprecated as of
2019.09 and will be
removed in a future
release.
Deprecation
Notice: Support
for Windows 7 is
deprecated as of
2019.09 and will be
removed in a future
release.
The following KBs

must be installed to
avoid errors when
capturing .NET
Core projects or
97
Supported platforms

analyzing .NET
web applications:
For Windows 7:
KB2533623
For Windows
8.1 and earlier
versions, or
Windows Server
2012 R2 and
earlier versions:
KB2999226
7.2.6. Supported compilers: Coverity Analysis for Java and Dynamic Analysis
Compiler support varies based on whether you use the cov-build command. Coverity Analysis for Java
and Dynamic Analysis supports the analysis of Java code that is built in two ways:
• [Recommended] Using cov-build. For information about this build mode, see the section called
"Coverity Analysis for Java analysis process" in the Coverity Analysis 2019.09 User and Administrator
Guide, and see the cov-build command documentation in the Coverity 2019.09 Command
Reference.
• Not using cov-build. For information about this build mode, see the section called "Alternative
analysis process flow" in the Coverity Analysis 2019.09 User and Administrator Guide, and see the
cov-emit-java command documentation in the Coverity 2019.09 Command Reference.
7.2.6.1. Supported compilers: Coverity Analysis (Quality analysis) for Java

Table 7.16. Supported Java compilers for static analysis
Host OS Compiler Compiler version Notes
macOS JDK for macOS 1.6 Deprecation notice:
JDK for macOS 1.6
is deprecated as of
2019.06 and support for
it will be removed in a
future release.
Linux/Windows (64-bit) OpenJDK 1.8, 11, 12 Deprecation Notice:
OpenJDK 12 is
deprecated as of
future release.
macOS/Linux/Windows Sun/Oracle JDK 1.7–1.8, 11, 12 JDK 1.7 is not supported
(64-bit) on Windows 10.
98
Supported platforms

Deprecation Notice:
Sun/Oracle JDK 12
is deprecated as of
future release.
7.2.6.2. Supported compilers: Dynamic Analysis for Java
Table 7.17. Supported Java compilers for dynamic analysis

macOS JDK for macOS 1.6 This is specific to the
Apple JDK for macOS.
Deprecation notice:
JDK for macOS 1.6
is deprecated as of
future release.
macOS/Linux/Windows Sun/Oracle JDK 1.7–1.8 Coverity does not
(64-bit) support Oracle JRockit
JDK
JDK 1.7 is not supported

on Windows 10.
Refer to the following list for details:
• Using Dynamic Analysis for Java requires either running cov-build or using the "Alternative analysis
process flow" as described in the Coverity Analysis 2019.09 User and Administrator Guide, and the
cov-emit-java command documentation in the Coverity 2019.09 Command Reference. Please refer
to Java Static Analysis for the list of Java supported compilers.
• The Dynamic Analysis Broker runs on the same platforms that support Java Coverity Analysis .
• The Dynamic Analysis Agent is supported on a v1.5, v1.6, and v1.7 Sun/Oracle HotSpot JVM, and on
the v1.6 Apple JVM that ships with the OS on supported macOS versions.
7.2.7. Supported compilers: Coverity Analysis for C/C++
Coverity provides, and supports the Compiler Integration Toolkit (CIT) (CIT). This toolkit is used to
integrate compilers with Coverity Analysis for C/C++. Coverity acknowledges that not all compilers can be
integrated using CIT. Coverity provides compiler integrations out of the box for many popular compilers
(listed below).
99
Supported platforms
Coverity provides commercially reasonable efforts to support documented compiler features driven by
market need. Coverity does not generally support undocumented or unintended language features. To
properly analyze files that use undocumented, unintended, or non-standard features, customers might
need to customize their configuration or change their code.
Non-CIT issues with compilers that have not been integrated by Coverity will be handled on a case by
case basis but are generally considered "unsupported". Since Coverity will not be able to validate these
issues, we will require very detailed and precise problem reports to begin the investigation.
Unless otherwise specified, Coverity does not support new or changed language features specified in:
• unpublished C and C++ language standards.
• C and C++ technical reports (TRs) or technical specifications (TSs).
Examples of such specifications include ISO/IEC TR 18037 (Programming languages—C—Extensions

to support embedded processors), ISO/IEC TS 19217:2015 (Information technology—Programming
languages—C++ Extensions for concepts), and ISO/IEC TS 21544:2018 (Programming languages—
Extensions to C++ for modules).
Coverity provides the following compiler integrations:
Table 7.18. Coverity Analysis for C/C++ compiler integrations

Compiler Version Host OS Target Notes
Analog Devices 8.5.0.0–8.12.0.0 Windows Blackfin ISO/IEC TR
Compilers 8.0.0.8–8.12.0.0 SHARC 18037 fixed point
extensions are
supported for C
(not C++) code
on Blackfin and
SHARC.
7.3.0.5 TigerSHARC
ARM C and C++ 5.0–6.10.1 Windows/Linux ARM
5.04 Windows Nintendo 3DS
Borland C++ CodeGear C++ Windows x86 The VCL library,
5.93 which is shipped
Borland C++ 5.5.1 with Borland
compilers, is not
supported.
CEVA compilers 17.0 Linux CEVA-X
b753 Windows CEVA-TL4CC
10.3–16.1 CEVA-XC321,
CEVA-XC323,
CEVA-XC4210,
CEVA-XC4500
b453 Windows/Linux CEVA-XM4
100
Supported platforms

Clang Android NDK Clang Windows, Linux, ARM, Hexagon, Clang compilers
3.1–3.4 (NDK macOS, FreeBSD MIPS, x86, x86_64 have various
revisions r8c-r9d) use limitations
Kyoto with Coverity
Microcomputer products, which
Clang 6.0 are listed in the
Coverity Analysis
LLVM Clang 3.0– 2018.09 User
8.0 and Administrator
Qualcomm Guide.
Hexagon 8.0.10
Coverity Analysis
Rynda Clang supports the
MISRA C:2004
and MISRA
C:2012 compliance
standards for Clang
compilers.
MISRA C:2012 rule

1.1 ensures that the
analyzed program
is compliant with
the C standard.
The Clang compiler
uses different
parse warnings and
error messages
than cov-emit
uses. You might
encounter minor
discrepancies
between the
enforcement of rule
1.1 by the Clang
compiler and cov-
emit.
Host OS support
for Linux is limited
to x86 and x86_64.
Linux on Itanium is
not supported.
Clang 3.3 with

Android NDK r9d
is not supported,
101
Supported platforms

please use clang
3.4 instead.
Clang compilers
are supported on
FreeBSD only on
version 11.1 or
later.
Cosmic C Cross cx6808 4.5.10– Windows Freescale 68HC08
Compilers 4.6.3 and HCS08
cx6812 4.6i Freescale 68HC12
and HCS12
cxs12x 4.7.7–4.8.9 Freescale HCS12X
cx332 4.1l Freescale
MC68332
cxstm8 4.3.7 STM8 and STLUX
family
cxxgate 4.2.4 Freescale XGATE
co-processor
cx6805 4.2d Motorola 68HC05
cx6811 4.1t Motorola 68HC11
cx6816 4.1r Motorola 68HC16
CrossWorks 3.1.0 Windows MSP430
4.0.1 ARM ISO/IEC TR
18037 fixed point
extensions are
supported for C
(not C++) code on
ARM.
Freescale 3.0 Windows ARM Codewarrior
Codewarrior 6.4 ColdFire compilers are
supported only
3.0 DS for command-line
DSC56800E builds. Coverity
Analysis does
4.0 DSi
not support the
3.0.5 E68k Codewarrior IDE.
4.2 EPPC 5xx
5.0.32 HC12
5.0.25 Microcontrollers
(HC08)
102
Supported platforms

4.2 MPC55xx
10.5 MSC815x
3.0 StarCore DSP
StarCore SDMA
4.3 Wii
3.0 Linux MSC815x
GNU GCC and G+ FSF GCC 3.0–9.1.0 FreeBSD, HP-UX, ARM, Itanium, ISO/IEC TR
+ Linux, macOS, MIPS, PowerPC, 18037 fixed point
NetBSD, Solaris, SPARC, x86, extensions are
Windows x86_64 supported for C
Kyoto Windows ARM (not C++) code.
Microcomputer gcc
GNU GCC
6.4.0
compilers
distributed with
Apple Xcode are
not supported.
Versions of any of
these compilers
that are modified
to accept non-
standard syntax are
not supported.
Only GNU GCC

and G++ 4.2.1
are supported on
FreeBSD 8.4.
Deprecation Notice:
Support for GNU
GCC and G++
4.2.1 is deprecated
on FreeBSD 8.4 as
of 2019.09 and will
be removed in a
future release.
Green Hills 4.0.7 Linux PowerPC
Optimizing C and C 4.2.3 Solaris PPC, MPC83xx,
++/EC++ PowerQUICC II
PRO
4.2.3–2018.1.4 Windows ARM
103
Supported platforms

4.0.2–2012.1 PowerPC
5.3 Wii U
2015.1 V850
2015.1.4–2018.1.4 Linux ARM
IAR Embedded 4.40A–8.11 Windows ARM
Workbench C/C++ 4.30–6.10 Atmel AVR
4.1 Atmel AVR32
1.13C–2.30 Dallas/Maxim
MAXQ
3.2 Freescale HCS12
4.10A–5.30 MSP430
3.1 National CR16C
1.3 Renesas RH850
2.10B–2.30 Renesas H8
2.21 Renesas RL78
2.3 Renesas SuperH
3.21D–3.50 Renesas M16C
3.21A–3.30 Renesas M32C
3.5 Renesas R8C
1.4 Renesas R32C
4.1 Renesas V850
3.2 Samsung SAM8
2.2 STM8
IBM XLC 8–13 AIX Power, PPC
Intel C++ 9.1–17.0.0 Linux x86
17.0.0–19.0.3 Windows
Keil Compilers RVCT 3.1, 4.0, 5.06 Windows ARM
for uVision
8.12–9.52 C51
6.11–7.53 C166
4.53a–5.55 C251
Marvell MSA 2.0, 3.1 Windows MSA
Microchip 1.42 Windows 8-bit PIC MCUs
Compilers XC8
104
Supported platforms

Microsoft 4.0 Windows ARM, MIPS, SH Deprecation
eMbedded C++ notice: Support
for the Microsoft
eMbedded C++
4.0 compiler is
deprecated as of
2019.09 and will be
removed in a future
release.
Microsoft bundles
compilers with
a number of
SDKs, such as the
Windows Driver
Kit, Window Driver
Development Kit,
and Windows CE.
These compilers
are similar to the
ones that come
with Visual Studio.
These compilers
are supported as
long as the version
number is greater
then 12.00, and the
target is supported.
The compiler
version can
be determined
by running the
compiler (`cl`)
on the command
line, which
returns detailed
information. For
example:
> cl
Microsoft (R) 32-bit

C/C++ Optimizing
Compiler Version
14.00.50727.42 for
80x86
105
Supported platforms

Copyright
(C) Microsoft
Corporation. All
rights reserved.
usage: cl
[ option... ]
filename... [ /link
linkoption... ]
Microsoft Visual C+ 2013–2019 Windows x86, x86_64, ARM Managed C++ and
+ Common Language
Runtime (CLR)
are not supported.
Compilations with
switches beginning
with "/CLR" will be
skipped.
Visual C++ 2013

and higher are the
only supported
compilers for
`FxCop` and `cov-
import-msvsca`.
The compiler
version can
be determined
by running the
compiler (`cl`)
on the command
line, which
returns detailed
information. For
example:
> cl
Microsoft (R) 32-bit

C/C++ Optimizing
Compiler Version
14.00.50727.42 for
80x86
Copyright
(C) Microsoft
106
Supported platforms

Corporation. All
rights reserved.
usage: cl
[ option... ]
filename... [ /link
linkoption... ]
Panasonic compiler 5.4R3 Windows MN103S, MN103L
QNX C/C++ 6.3.2–7.0.0 Windows/Linux ARM
Intel XScale
MIPS
PPC
SH-4
x86
Renesas C/C++ 1.02r01 Windows R32C
Compilers 1.03 RH850
RL78
1.0–2.03 RX
2.72 78k0r
3.47 CA850 (NEC V850)
5.01 M32R
5.41 M32C
M16C
6.02 H8
H8S
9.01–9.04 SuperH
1.31 V850
SONY PS4 SDK 1.000–6.000 Windows PS4 Sony PS4 is
supported only on
Windows 64-bit
systems.
Sun (Oracle) CC Studio8: CC and cc Solaris SPARC, x86
and cc 5.5
Studio9: CC and cc
5.6
Studio10: CC and
cc 5.7
107
Supported platforms

Studio11: CC and
cc 5.8
Studio12: CC and
cc 5.9
Studio12.1: CC and
cc 5.10
Studio12.2: CC and
cc 5.11
Studio12.4: CC and
cc 5.13
Synopsys I-2013.12 Windows/Linux ARC 600 ISO/IEC TR
MetaWare C and C ARC 700 18037 fixed point
++ Compilers (mcc/ extensions are
hcac binaries) ARC EM family supported for C
ARCompact (not C++) code.
ARCtangent-A4
Synopsys N-2017.09– Windows/Linux ARC EM family ISO/IEC TR
MetaWare C and C P-2019.03 ARC HS family 18037 fixed point
++ Compilers (ccac extensions are
binary) supported for C and
C++ code.
TASKING 5.2r1 Windows ARM Cortex
6.2r1 TriCore ISO/IEC TR
18037 fixed point
extensions are
supported for C
(not C++) code on
TriCore.
Tensilica Xtensa RA-2006.5 Windows/Linux x86
xt-xcc and xt-xtc++
compilers
Texas Instruments 5.1.0–7.6.0 Windows TMS320C6x TI compilers require
Code Composer 4.1.0–4.2.0 TMS320C54x an environment
variable to be
3.2.2–4.3.6 TMS320C55x set in order for
4.1.0–6.2.8 TMS320C2000 `cov-configure`
to properly probe
4.1.2–4.6.3 TMS470
compiler behavior.
17.3.0 ARM The environment
5.1.0–8.2.1 Linux TMS320C6x variable should
point to the include
4.1.0–6.2.8 TMS320C2000 directories, and
108
Supported platforms

15.12.3 ARM is specific to
the compiler
(for example,
`C6X_C_DIR`
for the C6000
compiler).
Wind River 5.0.x–5.9.x Windows/Linux ARM (XSCALE)
(formerly Diab) C/C ColdFire
++
M32R
MC68k
M*CORE
MIPS
PPC
SH
SPARC
TriCore
x86
4.3g Windows PowerPC
XBox One 17.0 Windows x86_64
Xcode (with Clang Apple Clang 6.0 macOS ARM, x86, x86_64
compiler) (Xcode 6.0-6.2)
Apple Clang 6.1
(Xcode 6.3-6.4)
Apple Clang 7.0
(Xcode 7.0-7.2)
Apple Clang 7.3
(Xcode 7.3)
Apple Clang 8.0
(Xcode 8.0-8.2)
Apple Clang 8.1
(Xcode8.3)
Apple Clang 9.0
(Xcode 9.0-9.2)
Apple Clang 9.1
(Xcode 9.3-9.4)
Apple Clang 10.0
(Xcode 10.0)
109
Supported platforms
Note
The Platform Builder IDE is supported if the compiler that it is using is supported. Platform Builder is
not a compiler.
7.2.8. Supported compilers: Coverity Analysis for Go

Table 7.19. Supported compilers: Coverity Analysis for Go
Compiler Compiler version Host OS Notes
Go 1.11.x Linux (64-bit) Coverity only supports
macOS projects that are built
with the following
Windows (64-bit) commands: go build, go
install, go run, and go
test. Coverity does not
support projects that are
built by invoking either
go tool compile or gccgo
directly.
Coverity does not

directly recognize
custom flags and
arguments of go run
or go test. In order for
Coverity to recognize
these custom flags and
arguments, you must
modify config/templates/
go/go_switches.dat.
Coverity requires the

GOPATH environment
variable to be set.
Coverity does not
support Go modules
or Go binary-only
packages.
7.2.9. Supported compilers: Coverity Analysis for Swift

Table 7.20. Supported compilers: Coverity Analysis for Swift
Compiler IDE Minimum Host OS Notes
Swift 4.2.x Xcode 10, Xcode 10.1 macOS 10.13.6 Swift 3.x is supported
through Swift 4.2.x
compiler's Swift 3
compatibility mode.
110
Supported platforms
Compiler IDE Minimum Host OS Notes

Swift 4.0.x and 4.1.x are
supported through Swift
4.2.x compiler's Swift 4
compatibility mode.
Coverity Analysis
supports Swift compiler
invocations via
xcodebuild. Swift
Package Manager is not
supported.
Deprecation Notice:
Support for macOS
10.12 is deprecated
as of 2019.03 and will
be removed in a future
release.
Deprecation Notice:
Support for Swift 4.2.x
is deprecated as of
2019.09 and will be
removed in a future
release.
7.2.10. Supported compilers: Coverity Analysis for Visual Basic

Table 7.21. Supported compilers: Coverity Analysis for Visual Basic

Visual Studio 2013–2019 Up to Visual Basic Windows 64- Visual Studio
15 bit workstation Express editions
releases Windows are not supported.
7 and later (except
for Windows 8.0) Deprecation
Notice: Support
.NET Core 2.0–2.1 Windows 64-bit
for Windows 7 is
server releases
deprecated as of
Windows Server
2019.09 and will be
2012 and later
removed in a future
release.
The following KBs

must be installed to
avoid errors when
capturing .NET
111
Supported platforms

Core projects or
analyzing .NET
web applications:
For Windows 7:
KB2533623
For Windows
8.1 and earlier
versions, or
Windows Server
2012 R2 and
earlier versions:
KB2999226
7.2.11. Supported compilers: Coverity Analysis for Scala

Table 7.22. Supported compilers: Coverity Analysis for Scala
Compiler IDE Host OS Notes
Scala 2.12.x Linux Scala supports Linux
Kernel v2.6.32 and later
7.2.12. Third-party supported compilers

Coverity Analysis tools can be run with certain third party owned and supported compilers. These third
party providers are solely responsible for supporting the compilers in question, and any issues with
misconfiguration should be fielded by the their support teams directly.
The following third party compilers are supported:
Table 7.23. Third-party supported compilers

Compiler Version CIT configuration
MPLAB XC8 1.36 Included in compiler distribution
MPLAB XC16 1.26
MPLAB XC32 1.42
7.3. Coverity Test Advisor SCM and platform support

The following tables list the platforms, compilers, and Source Control Management (SCM) systems that
are supported for C/C++, Java, and C# test environments.
The minimum system requirements are the same that are defined for Coverity Analysis. For more
information, see the Coverity Analysis.
Browser requirements are the same that are defined for Coverity Connect.
112
Supported platforms
7.3.1. Test Advisor supported compilers and platforms

Compiler and platform support varies by programming language.
7.3.1.1. Test Advisor for C/C++ supported compilers and platforms
Table 7.24. Test Advisor for C/C++ supported compilers and platforms
Supported Supported Supported OS Supported Notes

coverage tools compilers processor
architecture
gcov GNU GCC, G++ Linux N/A
version 3.4.6 to 6.x
Bullseye Bullseye-supported Linux N/A Test Advisor
compilers Windows support using
Bullseye requires
VxWorks a licensed
installation of the
BullseyeCoverage
tool. The minimum
supported
version of
BullseyeCoverage
is 8.7.53. For more
information about
BullseyeCoverage
implementation,
see the Test
Advisor 2018.09
User and
Administrator
Guide.
Bullseye supports
Wind River
VxWorks for Real
Time Processes
(RTPs), so
Test Advisor
can be used in
this situation.
Test Advisor
also supports
CoverageScope
for VxWorks Kernel
Modules. For more
information, see
Section 1A in
113
Supported platforms

architecture
the Test Advisor
2018.09 User
and Administrator
Guide.
Test Advisor
supports Bullseye-
supported
compilers, but only
those compilers
that are officially
supported by
BOTH Bullseye and
Coverity Analysis:
1. Locate the
particular compiler
as supported by
Bullseye on http://
www.bullseye.com/
platform.html.
2. Verify that
the compiler is
supported by
Coverity Analysis.
3. If the compiler
appears in both
support tables,
the compiler is
supported. If the
compiler ONLY
appears in the
Bullseye support
table, then the
compiler is not
supported by Test
Advisor.
Function Coverage GNU GCC, G++ Linux ARM, Intel- The Coverity
Instrumentation version 3.4.6 or compatible Function Coverage
later run-time library
must be recompiled
for ARM and
114
Supported platforms

architecture
deployed to the
target device in
order to collect
coverage data.
See the Coverity
Runtime Library
Development
Guide for more
information.
Visual Studio 2005 Windows Intel-compatible The compiler
C++ or later version can
be determined
by running the
compiler (cl) on
the command
line, which
returns detailed
information.
Managed C++ and

Common Language
Runtime (CLR)
are not supported.
Compilations with
switches beginning
with "/CLR" will be
skipped.
7.3.1.2. Coverity Test Advisor for Java supported compilers and platforms
Table 7.25. Test Advisor for Java supported compilers and platforms
Supported coverage Supported compilers Supported OS Notes

tools
Cobertura Sun/Oracle JDK, v1.5, Linux Test Advisor works only
v1.6, and v1.7 Windows with the shipped version
of Cobertura (1.9.4.1).
JaCoCo Sun/Oracle JDK, v1.5, Linux
v1.6, v1.7, and v1.8 Windows Deprecation notice:
Support for Sun/Oracle
JDK versions 1.5 and 1.6
is deprecated as of 8.7
and will be removed in a
future release.
115
Supported platforms
Supported coverage Supported compilers Supported OS Notes

tools
Test Advisor works only
with the shipped version
of JaCoCo (0.7.1).
Only JDK 1.8 is

supported on Windows
10.
Test Advisor ships

with the Cobertura and
JaCoCo open source
Java test coverage tools.
7.3.1.3. Coverity Test Advisor for C# supported compilers and platforms
Table 7.26. Test Advisor for C# supported compilers and platforms
Supported compilers Supported OS 32- or 64-bit Notes

Microsoft C# compiler Windows 32- or 64-bit Test Advisor ships with
the OpenCover open
source C# test coverage
tool.
7.3.2. Test Advisor supported SCM systems

SCM system support is identical for C/C++, C#, and Java.
Table 7.27. Test Advisor supported SCM systems for C/C++, C#, and Java
Supported SCM SCM version Supported OS Notes

systems
Accurev 7.0–7.2 Linux and Windows
ClearCase 9.0.0
CVS 1.11.17–1.12.13
Git 1.8–2.1, 2.2–2.21 Deprecation notice:
Support for Git 1.8–
2.1 is deprecated as
of 2019.06 and will be
removed in a future
release.
Mercurial 3.1–3.2, 3.3–4.5.3 Deprecation notice:
Support for Mercurial
3.1–3.2 is deprecated
116
Supported platforms
Supported SCM SCM version Supported OS Notes

systems
release.
Perforce 2015.2, 2016.1–2018.2 Deprecation notice:
Support for Perforce
2015.2 is deprecated
release.
Plastic 6.0.16.975–6.0.16.x
(where x is greater than
975)
SVN 1.4.0–1.9.4 Deprecation notice:
Support for SVN 1.4–
1.9 is deprecated as
of 2019.09 and will be
removed in a future
release.
Team Foundation TFS 2012 Windows Depends on TFS 2012
Server, powertools.
TFS 2012 Update 1 Depends on TFS 2012
Azure DevOps Server
update 1 powertools.
TFS 2012 Update 2 Depends on TFS 2012
update 2 powertools.
TFS 2013 Depends on TFS 2013
powertools.
TFS 2015 Depends on TFS 2015
powertools.
TFS 2017
TFS 2018
ADS 2019
Note
Team Foundation Version Control is the only SCM system that Coverity supports for Team
Foundation Server and Azure DevOps Server.
7.4. Architecture Analysis

Architecture Analysis supports the following platforms:
117
Supported platforms
Table 7.28. Architecture Analysis for C/C++ and C# platform support
Host OS Host OS or kernel Host CPU 32- or 64-bit Notes

version
Windows Windows Server x86_64 64-bit
2012
Windows 7,
Enterprise (no SP)
Windows 7,
Professional (no
SP)
Windows 7,
Ultimate (no SP)
Linux v2.6.32+, glibc x86 32- or 64-bit
2.14–2.27
macOS v10.12, v10.13– x86 32- or 64-bit Deprecation notice:
10.14 Support for macOS
10.12 is deprecated
as of 2019.06 and
future release.
Table 7.29. Architecture Analysis for Java platform support
Host OS Host OS or kernel Host CPU 32- or 64-bit Notes

version
Windows Windows Server x86_64 64-bit
2012
Windows 7,
Enterprise (no SP)
Windows 7,
Professional (no
SP)
Windows 7,
Ultimate (no SP)
Linux v2.6.32+, glibc x86 32- or 64-bit
2.14–2.27
macOS v10.12, v10.13– x86 32- or 64-bit Deprecation notice:
10.14 Support for macOS
10.12 is deprecated
as of 2019.06 and
future release.
118
Supported platforms
7.5. Coverity Desktop

7.5.1. Version Compatibility with Coverity Connect and Coverity Analysis.
The Coverity Desktop plug-ins require an active connection with a current version of Coverity Connect in
order to enable all analysis options. A Coverity Desktop plug-in is compatible with any Coverity Connect
instance of the same version, or any more recent version through the next major release (represented by
the first digit in the version number). For example, Coverity Desktop version 7.7 will be supported by all
Coverity Connect versions more recent than 7.7 and prior to 2019.09.
Note
Please note that the behavior described above is available starting with Coverity Desktop version
7.7. Coverity Desktop versions 7.6 and earlier must be connected to matching versions of Coverity
Connect.
The Coverity Desktop plug-ins require access to Coverity Analysis installed on the same machine.
Coverity Desktop and Coverity Analysis versions must match. Hotfix versions are considered as matching
the GA version (e.g., 7.7.0.x matches 7.7.0).
7.5.2. IDE and Java version support

Coverity Desktop supports the following IDE and Java versions.
Table 7.30. Supported IDE and Java versions

IDE IDE version Java version Notes
Visual Studio 2015–2019
Android Studio 2.3–3.4 Embedded JRE
Eclipse Eclipse 4.6, 4.7–4.12 Oracle Java 8–12 Deprecation notice:
IBM Rational Team Support for Eclipse
Concert (bundled with 4.6 is deprecated as
Eclipse) of 2019.06 and will be
removed in a future
ARM Development release.
Studio 5 (bundled with
Eclipse) Deprecation Notice:
Support for Java 12
is deprecated as of
2019.09 and will be
removed in a future
release.
Wind River WorkBench 3.3.1–3.3.6, 4.0 The Java Version
Intellij IDEA 2017.1–2019.1 column indicates the
Java version required
QNX Momentics 7.0 for the IDE to run. For
CLion 2017.2–2019.1 information regarding the
JDK version required for
RubyMine 2017.1.3–2019.1
119
Supported platforms
IDE IDE version Java version Notes

WebStorm Java code analysis, refer
to Supported compilers:
PyCharm
Coverity Analysis
PHPStorm (Quality analysis) for
Java in this chapter.
Deprecation Notice:
Support for Java 12
is deprecated as of
2019.09 and will be
removed in a future
release.
Note
The "Java Version" column indicates the Java version required for the IDE to run. For information
regarding the JDK version required for Java code analysis, refer to "Supported compilers: Coverity
Analysis (Quality analysis) for Java" in this chapter.
7.5.3. Coverity Desktop for Eclipse on supported platforms

Coverity Desktop for Eclipse is supported on the following platforms.
Table 7.31. Eclipse Plug-in platform support

Host OS Host OS or Host CPU Vendor IDE Supported Notes
kernel version and version languages
Windows Windows x86_64 Eclipse 4.6, C/C++, Java, Deprecation
workstation 4.7–4.12 JavaScript, Notice: Support
releases: PHP, Python, for Eclipse 4.6
Windows 7 and Ruby, and is deprecated
higher, except Scala as of 2019.06
for Windows and will be
8.0. removed in a
future release.
Windows server
releases: Deprecation
Windows Server Notice: Support
2012 and for macOS
higher. 10.12 is
Linux Linux Kernel deprecated
2.6.32+, glibc as of 2019.03
2.14–2.27 and will be
removed in a
macOS future release.
Coverity
requires a
120
Supported platforms

minimum
service pack
of SP1 for
Windows 7.
Deprecation
Notice: Support
for Windows 7
is deprecated
as of 2019.09
and will be
removed in a
future release.
7.5.4. Coverity Desktop for IBM Rational Team Concert (RTC) on supported
platforms
Coverity Desktop for IBM Rational Team Concert (RTC) version 6.0.6.1+ is supported on the following
platforms.
Table 7.32. IBM RTC Plug-in platform support

Windows Windows x86_64 Eclipse 4.6, C/C++, Java, Coverity
workstation 4.7–4.12 JavaScript, requires a
releases: PHP, Python, minimum
Windows 7 and and Ruby service pack
higher (except of SP1 for
for Windows Windows 7.
8.0).
Deprecation
Windows server Notice: Support
releases: for Windows 7
Windows Server is deprecated
2012 and as of 2019.09
higher. and will be
removed in a
future release.
Deprecation
Notice: Support
for Eclipse 4.6
is deprecated
as of 2019.06
and will be
121
Supported platforms

removed in a
future release.
Linux Linux Kernel Deprecation
2.6.32+, glibc Notice: Support
2.14–2.27 for Eclipse 4.6
is deprecated
as of 2019.06
and will be
removed in a
future release.
7.5.5. Coverity Desktop for ARM Development Studio 5 (DS-5) on supported

platforms
Coverity Desktop for ARM Development Studio 5 (DS-5) version 5.22+ is supported on the following
platforms.
Table 7.33. DS-5 Plug-in platform support

Windows Windows x86_64 Eclipse 4.6, C/C++ Coverity
workstation 4.7–4.12 requires a
releases: minimum
Windows 7 and service pack
8.0).
Deprecation
2012 and as of 2019.09
higher. and will be
removed in a
future release.
Deprecation
Notice: Support
for Eclipse 4.6
is deprecated
as of 2019.06
and will be
removed in a
future release.
122
Supported platforms

Linux Linux Kernel Deprecation
2.6.32+, glibc Notice: Support
2.14–2.27 for Eclipse 4.6
is deprecated
as of 2019.06
and will be
removed in a
future release.
7.5.6. Coverity Desktop for Wind River Workbench on supported platforms

Coverity Desktop for Wind River Workbench is supported on the following platforms.
Table 7.34. Wind River Workbench Plug-in platform support

Windows Windows x86_64 Wind River C/C++, Java, Coverity
workstation WorkBench JavaScript, requires a
releases: 3.3.1–3.3.6, 4.0 PHP, Python, minimum
8.0).
Deprecation
2012 and as of 2019.09
higher. and will be
removed in a
future release.
Linux Linux Kernel
2.6.32+, glibc
2.14–2.27
7.5.7. Coverity Desktop for QNX Momentics IDE on supported platforms

Coverity Desktop for QNX Momentics IDE is supported on the following platforms.
Table 7.35. QNX Momentics Plug-in platform support

Windows Windows x86_64 QNX Momentics C/C++, Java, Coverity
workstation 7.0 JavaScript, requires a
123
Supported platforms

8.0).
Deprecation
2012 and as of 2019.09
higher. and will be
removed in a
future release.
Linux Linux Kernel
2.6.32+, glibc
2.14–2.27
7.5.8. Coverity Desktop for Microsoft Visual Studio IDE on supported platforms
Coverity Desktop for Microsoft Visual Studio IDE is supported on the following platforms:
Table 7.36. Coverity Desktop for Microsoft Visual Studio IDE platform

Windows Windows x86_64 Visual Studio C/C++, Java, Coverity
workstation 2015–2019 JavaScript, requires a
8.0).
Deprecation
Notice: Support
for Windows 7
is deprecated
as of 2019.09
and will be
removed in a
future release.
7.5.9. Coverity Desktop for IntelliJ IDEA on supported platforms
Coverity Desktop for IntelliJ IDEA is supported on the following platforms.
124
Supported platforms
Table 7.37. IntelliJ IDEA Plug-in platform support

Windows Windows x86_64 IntelliJ 2017.1– C/C++, Java, Coverity
Windows 7 and Ruby, and service pack
higher (except Scala of SP1 for
8.0).
Deprecation
2012 and as of 2019.09
higher. and will be
removed in a
future release.
Linux Linux Kernel
2.6.32+, glibc
2.14–2.27
macOS macOS 10.12, Deprecation
10.13-10.14 Notice: Support
for macOS
10.12 is
deprecated
as of 2019.03
and will be
removed in a
future release.
7.5.10. Coverity Desktop for Android Studio on supported platforms

Coverity Desktop for Android Studio is supported on the following platforms.
Table 7.38. Android Studio Plug-in platform support

Windows Windows x86_64 Android Studio Java Coverity
workstation 2.3–3.4 requires a
releases: minimum
Windows 7 and service pack
8.0).
125
Supported platforms

Windows server Deprecation
releases: Notice: Support
Windows Server for Windows 7
2012 and is deprecated
higher. as of 2019.09
and will be
removed in a
future release.
Linux Linux Kernel
2.6.32+, glibc
2.14–2.27
10.13–10.14 Notice: Support
for macOS
10.12 is
deprecated
as of 2019.03
and will be
removed in a
future release.
7.5.11. Coverity Desktop for other IntelliJ-based IDEs on supported platforms

Coverity Desktop for other IntelliJ-based IDEs (such as RubyMine, WebStorm, PyCharm, PhpStorm, and
CLion) is supported for the following platforms.
Table 7.39. IntelliJ-based IDE Plug-in platform support

Windows Windows x86_64 CLion 2017.2– C/C++, Java, Coverity
Windows 7 and PhpStorm and Ruby service pack
higher (except 2017.1.3– of SP1 for
for Windows 2019.1 Windows 7.
8.0).
PyCharm Deprecation
Windows server 2017.1.3– Notice: Support
releases: 2019.1 for Windows 7
2012 and RubyMine as of 2019.09
higher. 2017.1.3– and will be
2019.1 removed in a
future release.
126
Supported platforms

Linux Linux Kernel WebStorm
2.6.32+, glibc 2017.1.3–
2.14–2.27 2019.1
10.13–10.14 Notice: Support
for macOS
10.12 is
deprecated
as of 2019.03
and will be
removed in a
future release.
127
Chapter 8. Coverity Connect system tuning, maintenance,
and monitoring
Table of Contents
8.1. Post-installation: what's next? ................................................................................................. 128
8.2. Coverity Connect system and database tuning ........................................................................ 130
8.3. Monitoring and diagnosing Coverity Connect performance ....................................................... 133
8.4. Deployment scenarios ............................................................................................................ 140
This part provides important information about tuning your system and database to ensure that your
system is achieving a high level of performance. In addition, this part provides guidelines for maintaining
the size of the Coverity Connect database, as well as tools that you can use to diagnose problems in
case the performance of your system seems sub-optimal.
8.1. Post-installation: what's next?

This section provides a list of tasks for you to perform to bring your entire deployment into production.
This section does not provide the "how to" information for each task, but references the documentation
that contains the information.
8.1.1. cov-analysis configuration and set-up

The tasks mentioned below are described in full in the Coverity Analysis 2019.09 User and Administrator
Guide .
Generate a compiler configuration

Before running your first code analysis, you typically generate a configuration of your native compiler.
Enable analysis checkers

Coverity runs checkers that detect specific types of issues in your source code. For example, the
RESOURCE_LEAK checker finds many types of resource leaks from variables that go out of scope
while "owning" a resource, such as freshly allocated memory. Checkers are classified by language
and grouped by the types of problems that they detect.
Create custom models to improve analysis results

A custom model is a piece of source code that is written by a developer to replace the actual
implementation of a function or method. Custom models can lead to a more accurate analysis by
helping Coverity find more issues and eliminate false positive results.
8.1.2. cov-platform system configuration and set-up

Except for performance tuning and monitoring, the tasks mentioned below are described in full in the
Configuring sign-in options

Controls user access to Coverity Connect.
128
Coverity Connect system tuning, maintenance, and monitoring
Setting up SSL
Configure Coverity Connect to encrypt communications using SSL.
Connecting to an LDAP database

The LDAP configuration feature for Coverity Connect allows site administrators to enter this
information only once, and all LDAP-compliant applications can use this central resource.
Configuring email notification

You can enable Coverity Connect to send email to notify developers of new issues or issues that
changed triage states.
Creating and/or importing users

Create or import users into your system. You can also create and organize users in groups.
Setting up role-based access control

Role-based access control (RBAC) is a feature that restricts system access to authorized Coverity
Connect users.
Creating streams and projects

You create a stream to support issue data on a portion of your code base. Each stream is organized
into a project, which can support multiple streams.
Creating data stores

A triage store is a repository for the current and historical triage values of CIDs. In Coverity Connect,
each stream must be associated with a single triage store so that users can triage issues (instances
of CIDs) found in the streams.
Configuring components
The components feature allows you to logically group source code files in named entities. Defining
components allows you to filter issues and files to show the relationship between source code and
development teams, assign issues to only the users or groups that are responsible for a particular
section of the code, and limit access to code and issues
Configuring and managing databases

Database size can be optimized for performance, and clean-up processes can be scheduled to
remove unneeded information. In addition, databases can be backed up and restored. Procedures
are provided for backing up and restoring embedded databases in both stand-alone and clustered
deployments.
Tuning the embedded database

See Section 8.2, “Coverity Connect system and database tuning”.
Tuning the Coverity Connect server

See Section 8.2, “Coverity Connect system and database tuning”.
Monitoring and diagnosing performance

See Section 8.3, “Monitoring and diagnosing Coverity Connect performance”.
8.1.3. The Coverity deployment maturity model

The deployment maturity model provided by Coverity consulting services is a program that takes
your deployment's level of maturity into consideration and works with you to craft a roadmap towards
129
successful adoption and integration of development testing into your development life cycle. Beginning
with a comprehensive understanding of your business goals, use cases and technical environment,
Coverity Professional Services will create a deployment plan based on a level-by-level assessment that
aligns with your organizational objectives.
8.2. Coverity Connect system and database tuning

This chapter provides a series of recommendations that you can implement in your Coverity Connect
deployment to help the system run more efficiently and more reliably. This section includes the following:
• Embedded PostgreSQL tuning parameters
• JVM tuning options (Java heap settings)
For more information about the PostgreSQL settings mentioned in this chapter, or for information about
tuning your external database, see the PostgreSQL documentation at https://wiki.postgresql.org/wiki/
Tuning_Your_PostgreSQL_Server.
Tuning Coverity Connect and its related components is an iterative process that can vary for different
deployments. Each deployment is unique and might require further customization to suit specific
requirements. It is recommended to keep detailed records of your tuning and configuration settings in
case you need to revert your changes.
Note
Note that after you make any tuning changes, you will need to restart the Coverity Connect
application and database. For more information, see Section 1.4.4, “Stopping and starting Coverity
Connect”.
8.2.1. PostgreSQL database tuning: embedded database

When you run the 2019.09 Coverity Connect installer, you select a database performance level for a
Production or Demo system. The selected level applies changes to both the PostgreSQL database
configuration that is embedded with Coverity Connect and the JVM. These changes balance the memory
utilization so that approximately 75% of RAM is allocated to the JVM and the remaining 25% is allocated
to PostgreSQL and the operating system cache. The allocation of memory in this fashion is to avoid disk
swapping by either the application or the database. This new memory allocation strategy biases memory
towards the JVM to allow the application to scale under heavier loads without impacting database
performance.
You can see the settings stored for your environment and installation by executing the cov-admin-db
tune --read command.
8.2.1.1. Modifying the database configuration file

To change your PostgreSQL database configuration, you can edit the postgresql.conf. This file is in
the following location, if you chose the default location during the installation or upgrade:
• <install_dir_cc>/database/ (Unix systems)
• <install_dir_cc>\database\ (Windows systems)
130
If you update the database configuration, you must use the instructions in PostgreSQL Performance
Tuning or follow the direction of Coverity Support. Incorrect configuration updates can prevent Coverity
Connect from starting or cause Coverity Connect to perform poorly. Note that you can recover from this
error by restoring the configuration file to its original state.
Table 8.1. postgres.conf settings

Parameter Setting and notes
shared_buffers 512MB. (Due to the way PostgreSQL is implemented in Windows, the
maximum value for shared_buffers is 512MB. On Windows, PostgreSQL relies
heavily on OS caching. This limits the ability to tune memory on this platform
and impacts performance negatively.
work_mem This amount is allocated per session for operations such as sorts (Coverity
Connect usually spawns ~30) threshold for disk-based sorts. If it calls for more
space, the sort will happen on disk (which is much slower).
Depends on storage device/system. (16 assuming that you are restoring onto
effective_io_concurrency
an OWC drive. Allocates approximately 4000 I/Ops per process. Otherwise,
it should be equal to the number of drives in your RAID array or 1 for a single
drive).
wal_buffers 16MB (for the write-ahead-log. Only requires enough space for logging, not
queries).
checkpoint_segments128 (more segments means less log writing contention) .
track_counts on/true (stats required for vacuum).
1GB (embedded DB) the threshold amount the postgreSQL uses to determine
effective_cache_size
if queries can be managed in memory. Does not count toward actual mem
usage.
autovacuum Automates the execution of VACUUM and ANALYZE commands. When set
to on, this option checks for tables that have had a large number of inserted,
updated, or deleted tuples. These checks use the statistics collection facility;
therefore, autovacuum cannot be used unless track_counts is set to
true. In the default configuration, autovacuuming is enabled and the related
configuration parameters are appropriately set.
4 (multiply by maintenance_work_mem to figure out the RAM footprint
autovacuum_max_workers
imposed by concurrent autovacuum processes) counts to the total number of
connections (max_connections). large values may skew require PostgreSQL
shared_buffers requirement. May require retuning the kernel.shmmax and
kernel.shmall parameters based on guidance provided in the pgctl.log.
You must stop and restart Coverity Connect after you change these parameters. Use cov-im-ctl
stop to stop Coverity Connect and cov-im-ctl start to restart it.
8.2.1.2. Windows limitations

Limitations for PostgreSQL on Windows include the following:
• shared_buffer cannot exceed 1GB.
131
• effective_io cannot be used to improve performance. Enabling this feature under Windows will
prevent PostgreSQL from starting.
8.2.1.3. Maintaining and backing up the database

After you have deployed the Coverity products and have brought your system into production, proper
maintenance and backup must be performed. For more information, see the Coverity Platform 2019.09
User and Administrator Guide.
8.2.2. JVM settings

This section includes tuning recommendation for the Java Virtual Machine. JVM parameters for Coverity
Connect must be placed in the <install_dir_cc>/config/system.properties files in the
java_opts_post attribute. Do not use quotes. This allows the default parameters to be overridden.
To display your current JVM options, use the following command:

java -server -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version
During installation, Coverity Platform sets the following JVM parameters, depending on the performance
tuning options you chose:
For Production installation tunings:

-Xms512m
-Xmx<75% of the Total System Memory>
8.2.2.1. Required JVM settings

Table 8.2. Required JVM settings
Parameter Setting and notes
-server Explicitly set the server runtime (as opposed to the
client runtime). There are no additional arguments.
-Xms Set the minimum heap size. Example usage:
-Xms512m
-Xmx Set the maximum heap size. Example usage:
-Xmx8g
8.2.2.2. Optional JVM settings

The following parameters are optional, but are recommended for optimization:
Table 8.3. Optional JVM settings

Parameter Settings and notes
-xx:+UseCompressedOops Enable (+) the use of 32-bit ordinary object pointers
in 64-bit JREs. Enabling this parameter can provide
faster and more efficient 32-bit addressing for
132
Parameter Settings and notes

OOPs at the expense of heap size. Note that the
heap will be limited to a maximum of 32Gb.
-XX:-UseGCOVerheadLimit Disable (-) the garbage collection overhead
limit. When this parameter is disabled,
OutOfMemoryExceptions are suppressed
when more than 98% of the total time is spent in
garbage collection and less than 2% of the heap is
recovered. Note that this might allow the application
to hang when the heap is under-provisioned.
8.3. Monitoring and diagnosing Coverity Connect performance

This section provides information about tools that you can use to monitor the performance of your
system. It is highly recommended that you establish a monitoring schedule or policy within your
organization so that you can continually record performance numbers. This way, you can track system
performance trends over time to assess the health of the system.
Additionally, this section provides tools that will help you diagnose issues if you suspect that there is a
degradation in performance.
8.3.1. Linux monitoring and diagnosis tools

You can use the following commands to monitor and diagnose the performance of your Coverity Connect
deployment on Linux:
CPU Core Count

The following command will help you monitor CPU usage. Note that this does not count
hyperthreading (even if it is enabled):
# cat /proc/cpuinfo | egrep "core id|physical id" | tr -d "\n" | sed s/physical/\
\nphysical/g | grep -v ^$ | sort | uniq | wc -l
Total RAM
The following command will help you monitor the total RAM usage:
# cat /proc/meminfo | grep MemTotal
Shared Memory
The following commands allow you to view the RAM that is shared between applications on your
system.
# sysctl -a | grep kernel.shmmax
# sysctl -a | grep kernel.shmall
8.3.1.1. Diagnosing performance problems

You can use the Linux/Unix top command as a preliminary diagnosis tool for performance-related
problems. The following table lists the tools that you can use to diagnose performance problems with
top.
133
Table 8.4. top command options

Option Description
iowait iowait (or just wa) displays the percentage of
time that the CPU (or CPUs) were idle during which
the system had an outstanding disk I/O request.
Sustained values higher than 5-10% can indicate
that an IO bottleneck exists. This command might
display misleading values and should be used with
other fields to support/deny a particular diagnosis
path.
SWAP SWAP contains statistics about swap space. The
SWAP field can be turned on to show swap size
for each process. High values coupled with high
iowait give a strong indication of thrashing.
Processes with high SWAP values need to be
tuned in order to decrease the swap space.
Mem Contains statistics on memory usage. Usage
values nearing the physical memory in the
machine, coupled with a large swap space, indicate
the need for additional RAM. It is recommended
that the amount of RAM be at least 25% of the
database size.
The database size can be found in Coverity

Connect by navigating to Help → About... →
Database Size.
For usage information, see the http://linux.die.net/man/1/top .
8.3.1.2. Diagnosing I/O problems

If an I/O bottleneck is presumed to exist in the system, iostat can assist in finding it. The following table
lists the recommended options that you can use to diagnose performance problems with iostat. Run
iostat with -x to see all fields.
Table 8.5. top command options

Option Description
svctm and await Displays the number of milliseconds spent servicing
requests. High values indicate that the device
might be overloaded. Spikes in svctm and await
are usually normal and only drives that show
persistently slow service times should raise
alarm. You can try running iostat -d 1 -x >
iostatout.txt to look at persistent data. This
will measure I/O every second for as long as it is
left to run.
134
Option Description
%util A value of 100% means the device is saturated with
requests.
avgqu-sz Indicates the average queue size. High values
along with high svctm, await and %util values
near 100% likely means the device is overloaded
with read/write requests.
For usage information, see http://linux.die.net/man/1/iostat .
8.3.2. Windows monitoring and diagnosis tools

You can use the following commands to monitor and diagnose the performance of your Coverity Connect
deployment on Windows:
CPU Core Count

The following command will help you monitor the CPU usage.
# systeminfo | findStr "Processors(s)"
Total RAM
The following command will help you monitor the total RAM usage:
# systeminfo | findStr "Total Physical Memory"
8.3.2.1. Using the Performance Monitor to diagnose Coverity Connect issues

The Performance Monitor for Windows shows persistent values for various system statistics including
CPU, RAM and I/O Counters. The following example shows an overview of how to use the Performance
Monitor on Windows 7. Note that this is just an example. For usage information, see the Performance
Monitor documentation at http://technet.microsoft.com/en-us/library/dd744567(v=WS.10).aspx .
1. Open the Performance Monitor.
2. Click Monitoring Tools / Performance Monitor in the Console Tree (the menu on the left).
3. Click the green plus sign on the top bar of the Performance Monitor screen.
4. Add the counters you want to measure from the list and then click OK.
5. On the right side, select More Actions → New → Data Collector Set. Follow the prompts to create the
logs.
6. Click Data Collector Sets → User Defined → <name of the set you just created> in the
Console Tree.
7. Click the Play button on the top toolbar.
8. Attempt the task which is under-performing or failing to complete (commit, upgrade, viewing issues,
triaging, and so forth).
9. Press the Stop button.
135
10.You can now view the data by clicking the view latest report button (a small green log book icon) on
the top toolbar.
Use the following descriptions to diagnose the performance issue:
Table 8.6. Defect event processing
Option Description
CPU Counters
Processor \ % Interrupt Time Measures the time the processor spends receiving
and servicing hardware interruptions during specific
sample intervals. This counter indicates a possible
hardware issue if the value is greater than 15%.
System \ Processor Queue Length This indicates the number of threads in the
processor queue. The server doesn't have enough
processor power if the value is more than two times
the number of CPUs for an extended period of time.
I/O Counters
LogicalDisk \ % Free Space Measures the percentage of free space on the
selected logical disk drive. Take note if this falls
below 15%, as you risk running out of free space
for the OS to store critical files. One solution is to
add more disk space.
PhysicalDisk \ Avg. Disk Queue Length Indicates how many I/O operations are waiting for
the hard drive to become available. If the value is
larger than the two times the number of spindles,
that means the disk itself may be the bottleneck.
This is of particular interest when considering a
RAID array as a single disk that may become
overloaded as a result of the configuration.
PhysicalDisk \ % Idle Time Measures the percentage of time the disk was
idle during the sample interval. If this counter falls
below 20 percent for an extended period of time,
the disk system is saturated. Replacing the current
disk system with a faster disk system may be
warranted. Note that this alone is not a very strong
indicator of an existing problem.
PhysicalDisk \ Avg. Disk Sec/Read Measures the average time, in seconds, to read
data from the disk. If the number is larger than 10
milliseconds (ms), that means the disk system is
experiencing latency when reading from the disk. It
is recommended to replace the current disk system
with a faster disk system if possible.
PhysicalDisk \ Avg. Disk Sec/Write Measures the average time, in seconds, it takes to
write data to the disk. If the number is larger than
136
Option Description
10 ms, the disk system is experiencing latency
when writing to the disk. It is recommended to
replace the current disk system with a faster disk
system if possible.
Memory Counters
Memory \ % Committed Bytes in Use Measures the ratio of Committed Bytes to the
Commit Limit—in other words, the amount of
virtual memory in use. Ideally this should be zero
or very small. This indicates insufficient memory
if the number is greater than 80%. It probably
indicates thrashing. Check the Pool Paged Bytes
and Avaliable Mbytes (see below).
Memory \ Available Mbytes Measures the amount of physical memory, in
megabytes, available for running processes. If this
value is less than 5% of the total physical RAM,
that means there is insufficient memory, which can
increase paging activity. To resolve this problem,
you should add more memory.
Memory \ Pool Paged Bytes Measures the amount of physical memory, in
megabytes, available for running processes. If
this value is less than 5% of the total physical
RAM, that means there is insufficient memory, and
that can increase paging activity. To resolve this
problem, you should add more memory.
Memory \ Pages per Second Measures the rate at which pages are read from
or written to disk to resolve hard page faults. If the
value is greater than 1,000, as a result of excessive
paging, tuning the JVM and PostgreSQL settings is
likely required.
Network Counters
Network Interface \ Bytes Total/Sec Measures the rate at which bytes are sent and
received over each network adapter, including
framing characters. The network is saturated if you
discover that more than 70 percent of the interface
is consumed. For example, for a 100-Mbps NIC,
the interface consumed is 8.7MB/Sec (100Mbps
= (100Mb)*(1MB/8Mb)/Sec = 12.5MB/Sec =>
12.5MB/Sec*(0.7) = 8.7MB/Sec).
Network Interface \ Output Queue Length Measures the length of the output packet queue, in
packets. There is network saturation if the value is
more than 2 for an extended period of time.
137
8.3.3. System performance reference

The following numbers demonstrate a typical system with very good performance. These numbers are
not meant for you to compare to your system, because any number of variables can add or subtract from
your build, commit, or analysis times. This is simply provided as an example.
The hardware for this system is as follows:
• Supermicro X9DR3-F/X9DR3-F, BIOS 2.0 01/30/2013
• Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz stepping 07 (8-core single CPU)
• 64GB RAM
• OWC Mercury EXTREME Pro 6G SSD (SATA III mode)
For system configuration settings, the system uses the recommended JVM and PostgreSQL default
settings. The memory is optimized for 8GB of total RAM.
8.3.3.1. Build
13:13:15 cov-emit phase: 1047 seconds.
8.3.3.2. Analysis
13:32:28 Analysis summary report:
13:32:28 ------------------------
13:32:28 Files analyzed : 4425
13:32:28 Total LoC input to cov-analyze : 2858216
13:32:28 Functions analyzed : 84963
13:32:28 Paths analyzed : 6174509
13:32:28 Time taken by analysis : 00:19:13
13:32:28 Defect occurrences found : 4539 Total
13:32:28 1 ALLOC_FREE_MISMATCH
13:32:28 50 ARRAY_VS_SINGLETON
13:32:28 1 ASSERT_SIDE_EFFECT
13:32:28 154 ATOMICITY
13:32:28 3 BAD_COMPARE
13:32:28 9 BAD_FREE
13:32:28 2 BAD_SIZEOF
13:32:28 21 BUFFER_SIZE
13:32:28 48 BUFFER_SIZE_WARNING
13:32:28 251 CHECKED_RETURN
13:32:28 100 CONSTANT_EXPRESSION_RESULT
13:32:28 16 COPY_PASTE_ERROR
13:32:28 280 DEADCODE
13:32:28 30 DIVIDE_BY_ZERO
13:32:28 51 EVALUATION_ORDER
13:32:28 426 FORWARD_NULL
13:32:28 15 INCOMPATIBLE_CAST
13:32:28 6 INFINITE_LOOP
13:32:28 73 INTEGER_OVERFLOW
138
13:32:28 151 LOCK

13:32:28 255 MISSING_BREAK
13:32:28 242 MISSING_LOCK
13:32:28 9 MIXED_ENUMS
13:32:28 25 NEGATIVE_RETURNS
13:32:28 20 NESTING_INDENT_MISMATCH
13:32:28 406 NO_EFFECT
13:32:28 103 NULL_RETURNS
13:32:28 23 ORDER_REVERSAL
13:32:28 28 OVERFLOW_BEFORE_WIDEN
13:32:28 317 OVERRUN
13:32:28 2 PASS_BY_VALUE
13:32:28 10 PW.ASSIGN_WHERE_COMPARE_MEANT
13:32:28 1 PW.BOOLEAN_CONTROLLING_EXPR_IS_CONSTANT
13:32:28 6 PW.BRANCH_PAST_INITIALIZATION
13:32:28 12 PW.CONVERSION_TO_POINTER_ADDS_BITS
13:32:28 8 PW.INCLUDE_RECURSION
13:32:28 2 PW.MISSING_INITIALIZER_ON_CONST
13:32:28 52 PW.PARAMETER_HIDDEN
13:32:28 5 PW.PARAM_SET_BUT_NOT_USED
13:32:28 54 PW.POINTER_CONVERSION_LOSES_BITS
13:32:28 14 PW.PRINTF_ARG_MISMATCH
13:32:28 17 PW.SIGNED_ONE_BIT_FIELD
13:32:28 2 PW.SWITCH_SELECTOR_EXPR_IS_CONSTANT
13:32:28 2 PW.USELESS_TYPE_QUALIFIERS
13:32:28 135 RESOURCE_LEAK
13:32:28 2 RETURN_LOCAL
13:32:28 168 REVERSE_INULL
13:32:28 13 REVERSE_NEGATIVE
13:32:28 61 SIGN_EXTENSION
13:32:28 9 SIZECHECK
13:32:28 20 SIZEOF_MISMATCH
13:32:28 1 STACK_USE
13:32:28 5 STRAY_SEMICOLON
13:32:28 8 STRING_NULL
13:32:28 1 STRING_SIZE
13:32:28 3 SWAPPED_ARGUMENTS
13:32:28 355 TAINTED_SCALAR
13:32:28 4 TAINTED_STRING
13:32:28 7 TOCTOU
13:32:28 199 UNINIT
13:32:28 32 UNREACHABLE
13:32:28 114 UNUSED_VALUE
13:32:28 85 USE_AFTER_FREE
13:32:28 14 VARARGS
13:32:28
13:32:28 cov-analyze: 1153 seconds.
8.3.3.3. Commit
13:32:30 2013-05-09 20:32:30 UTC - Committing 6597 file descriptions...

13:32:38 2013-05-09 20:32:38 UTC - Committing 6583 source files...
13:33:37 2013-05-09 20:32:30 UTC - Calculating 6597 cross-reference bundles...
139
13:33:37 2013-05-09 20:33:37 UTC - Committing 6597 cross-reference bundles...

13:34:42 2013-05-09 20:34:42 UTC - Committing 84963 functions...
13:36:30 2013-05-09 20:36:30 UTC - Committing 4539 defect occurrences...
13:38:44 2013-05-09 20:38:44 UTC - Committing 4 output files...
13:39:07 New snapshot ID 10031 added.
13:39:07 Elapsed time: 00:06:38
8.4. Deployment scenarios

This section describes several full deployment scenarios of software organizations that use Coverity
products. These scenarios demonstrate how various organizations with different infrastructures deployed
Coverity Analysis and Coverity Platform and show the possibilities for improved efficiencies in the
organization.
The use cases depict the following deployment scenarios:
• Section 8.4.1, “Scenario 1: Increasing the number of concurrent commits”
• Section 8.4.2, “Scenario 2: Optimal performance for commits, application performance, and UI
response”
• Section 8.4.3, “Scenario 3: Increasing performance over time”
These scenarios are directed at build engineers, systems administrators, enterprise architects, and
systems architects. The goal of these scenarios is for you to understand how similarly-sized organizations
(in relation to your organization) deployed and implemented Coverity products.
Each scenario describes a deployment story including the initial state of the deployed environment, the
issues facing the deployment, and the hardware, software, and feature options that were put in place so
that the performance goals were achieved. This way, you can plan for your deployment to run optimally
upon installation and configuration.
8.4.1. Scenario 1: Increasing the number of concurrent commits

In this use case scenario, a business unit in a telecommunications company uses Coverity products
to increase the quality of their released and internal-use software. As the organization integrated the
analysis process into their build process, there was a need to configure the system to increase the
number of concurrent commits, increase performance, and manage the size of the database. The story
below describes the process of how this organization achieved these goals.
8.4.1.1. Goals
The overall goals for this organization's Coverity product deployment are as follows:
1. Primary goal - Improvement of commit concurrency
2. Secondary goal - Troubleshoot Coverity Connect Web Services to improve and stabilize performance
3. Future goal - Expand the use of Coverity Connect from 50% to 70% of users
140
8.4.1.1.1. Challenges and issues
The primary challenges and issues for this use case were as follows:
• The objective of the product deployment team was to efficiently use the hardware resources allocated
for a number of Coverity Connect instances which were experiencing difficulty scaling concurrent
commits. Given the size and number of commits being generated by the build process, the database
size was also increasing at an unsustainable rate.
• The objective of the integration team was to continue to be able to perform auto-triaging of defects
(such as auto-assignment and notification) using existing or newer versions of the web services API.
This integration used a Python script invoked by the build process. Given the initial performance
difficulties, the organization experienced issues automating snapshot deletion through web services
(such as slow or incomplete operations) and was unsure if this was related to performance, changes in
the web service API behavior, or flaws in the integration script.
8.4.1.2. Deployment story

The organization's basic deployment infrastructure is as follows:
• primary load - Build system integration and automated triage scripts using web services
• number of Coverity users - approximately 3000
• number of lines of code - approximately 14 million lines
• products - the products of this organization are based off of the Android platform and have both C and
Java components.
• Feature branch aggregation - All code branches are essentially different feature branches derived from
a common source with target-specific hardware.
• Coverity Analysis runs on build machines which are run as a cluster. The organization uses LFS
for scheduling the builds against target platforms which meet run requirements. While builds are
scheduled in parallel, the execution is highly dependent on the availability of the required platforms.
• There are 16 variants of the code base (a variant is source code from a common base which has slight
variations, such as different hardware/software platforms). Each variant consists of market level tiers,
which equates to approximately 40 different code branches with a significant amount of shared code.
Branches are categorized into system development branches and release branches.
• The organization has approximately 30 Coverity Connect instances consisting of both production and
staging machines. All are standalone instances with embedded PostgreSQL databases.
8.4.1.2.1. Release process
The release process is as follows:
1. Nightly builds are run using all Coverity Analysis checkers enabled.
2. Towards the end of the release, an architect or manager triages high value issues uncovered by the
analysis.
141
3. Issues are imported into a third-party bug tracking system (JIRA/ClearQuest).
4. Developers fix the assigned defects. Progress is tracked daily using project reports in Coverity
Connect.
5. When the enabled checkers no longer report issues, the product is considered to be "Clean" and is
ready to release.
8.4.1.2.2. Preconditions
The following section describes the conditions that must be implemented or accepted in order to
complete the optimization of the deployment:
• Sufficient resources for the optimization process (see Section 8.4.1.2.4, “Hardware”). Generally,
the RAM should be no less than 25% of the database size. Initially, the organization had an 800GB
database. The size of the database was reduced using manual snapshot deletion to approximately
350GB.
• The ability to isolate build behavior from integration behavior. Each could be triggered separately to be
able to diagnose them in isolation.
• The ability to make configuration changes to the Coverity Connect configuration files as well as any
underlying operating system parameters.
• A staging environment to test changes, or the ability to restart production systems during the diagnosis
procedure.
8.4.1.2.3. Diagnostics
This section describes the actions that identity the problem with a particular aspect of the deployment and
implement configuration or feature changes to improve or solve the problem.
• Optimization of the JVM, PostgreSQL, and OS settings - Given the size of the database, a large
amount of the 256GB of RAM was allocated to the Coverity Connect PostgreSQL database (128GB).
The JVM was given 64GB. This tuning required changes to the underlying shared memory parameters
in Linux (see the tuning information). All changes were done on the production instance of the Coverity
Connect server due to the limited impact of downtime, but moving forward, a staging instance is going
to be used.
• After the above optimizations were in place, the commit concurrency threshold was increased from
the default of 5 and also specified a commit queue of 100. The organization tried commit concurrency
thresholds 8, 16, and finally 24. During testing, the load was monitored on the Coverity Connect server
to ensure that resources were not overcommitted. Given the 24 hour job threshold, the combination of
performance tuning allowed the organization to easily reach the acceptance criteria of 8 commits over
24 hours.
• After performance was optimized, it was determined that the Coverity Connect Web Services API
integration scripts were failing due to changes in the API. Corrective action required involvement of
professional services which required migration to V6 of the Web Services API and changes to the
existing scripts.
142
8.4.1.2.4. Hardware
The organization uses the following hardware configuration for Coverity tool deployment:
• Vendor: Dell PowerEdge R620 Rack Mount Server
• CPU: Intel Xeon E5-2680 2.70GHz, 20M Cache, 8.0GT/s QPI, Turbo, 8Cores, 130W, Max Mem
1600MHz x 2 (Total 16 cores/32 Hyperthreaded)
• Memory: 256GB @ 1600MHz
• Hard Drives: 300GB 15K RPM SA SCSI 6Gbps 2.5in Hotplug Hard Drive (342-2240) - Quantity 8 /
RAID 10
• RAID Controller: H710
• Rack Size: 1U
8.4.1.2.5. Custom configuration and tuning settings
The following system parameters were set for optimal performance.
In system.properties:
• tomcat_max_heap=auto
• java_opts_post=-server –Xms512m –Xmx192g
In postgresql.conf:
• shared_buffers=16GB
• work_mem=32MB
• maintenance_work_mem=8GB
• effective_io_concurrency=4
• wal_buffers=32MB
• checkpoint_segments=128
• effective_cache_size=64GB
8.4.1.3. Future considerations
The following items are recommendations that the organization can integrate (but have not yet
implemented) into their deployment to further optimize performance and storage space:
• The current deployment uses one triage store per stream. This was a consequence of migration, in
which the organization was unaware of the implications of this decision. This is less than ideal as
143
triage information is duplicated between project variants. The adoption of a clustered Coverity Connect
(coordinator/subscriber model) might also help manage future database scalability issues.
• The use of the purge snapshot details in Coverity Connect would allow the organization to manage
database growth through the supported mechanism, instead of using the snapshot deletion
mechanism.
Recommended that the organization manage the size of their database and improved performance
using a the purge snapshot details feature and a subsequent back-up and restore operation.
8.4.2. Scenario 2: Optimal performance for commits, application performance,

and UI response
In this use case scenario, a software organization of a computer storage company uses Coverity
to measure quality. After initial deployment, there was a need to configure the system to increase
the number of concurrent commits, to increase performance, and to increase the performance and
responsiveness of the Coverity Connect user interface. The story below describes the process of how this
organization achieved these goals.
8.4.2.1. Goals
The overall goals for optimizing this organization's Coverity product deployment are as follows:
1. Primary goal - Improvement of commit concurrency to scale for the desktop deployment model.
2. Primary goal - Improvement of application/database performance.
3. Primary goal - Improvement of UI responsiveness, particularly logging in, as it used as a measure of

the application's responsiveness.
4. Secondary goal - Validation of Coverity-recommended best practices.
5. Future goal - Improvement of the upgrade process.
8.4.2.1.1. Challenges and issues
The primary challenges and issues for this use case were defined as follows:
• The core application group uses Coverity tools to manage the quality of embedded software used by
various ASIC families and the product branches based on these families. The objective of this group
was to scale commits (and the database) to be able to keep up with the approximately 1000 streams
being managed by Coverity Connect.
• The initial environment consisted of a VMWare ESXi virtualized application server (with 2 CPUs and
8GB of reserved RAM) against a standalone database. The ESXi host was provisioned with 2x Intel
x5550 (for a total of 8 cores) and 144GB of RAM connected to 8Gb FC Storage. All guest VMDK files
are on VMFS3 formatted data stores.
The Coverity Connect VM ran alongside 15 other VMs with fewer resources assigned. This
configuration did perform given the targeted deployment scope. Dedicated enterprise hardware was
deployed for both the application and database layers (which are separate) to address performance
144
issues but challenges still remained with regards to configuring the application environment to take
advantage of these additional resources.
• Given the number of full commits being generated by both automated builds and developers, database
size was increasing at an unmanageable rate which forced the organization to use the snapshot
deletion process to manage database growth. As well as impacting performance, delete operations
also prevented them from instituting an audit policy for their clean-before-checkin process.
• Due to the high criticality of Coverity integration to their development process, measures were taken to
ensure high availability.

The organization's basic deployment infrastructure is as follows:
• Primary load - Full (not partial) local developer desktop commits and baseline commits used for defect
comparison (pre-report preview).
• number of Coverity users - approximately 600
• number of lines of code - approximately 1.6 million lines
• products - The organization produces embedded software created in C and Assembly.
• Cross platform aggregation - browse and fix current issues regardless of target platform.
• The current Coverity Connect deployment is centralized to one location, but is used by three
geographically distributed and one local design center. All commits happen locally to the centralized
Coverity Connect instance.
• A dedicated build machine is used to create baseline commits of their projects, which are used for
comparison against local developer commits. This comparison is accomplished by using a Web
Services-based script that emulates the preview report functionality in an older version of Coverity
Connect (in which this feature did not exist).
• Clean before check-in process
1. The central build machine processes important branches with Coverity targets to serve as the
baseline for comparison.
2. Desktop integration via Perforce performs a pre- check-in operation which involves committing local
results to the central Coverity Connect instance and comparing the baseline to the desktop commit.
3. New and removed defects are reported back to the developer.
8.4.2.2.1. Development process
The organization's development process is as follows:
1. Desktop integration through Perforce performs a pre-check-in operation which involves committing
local results to the central Coverity Connect instance and comparing the baseline to the Coverity
Desktop commit.
145
2. New and removed issues are reported back to the developer.
• Given the high-availability requirements for Coverity Connect, 3 separate environments were
available (Production, Standby, and Development). The ability to compare behaviors in these
environments proved useful in diagnosing the impact of snapshot deletion on application performance
(Section 8.4.2.2.4, “Diagnostics”). In addition, configuration changes could be applied to the
Development environment without impacting Production.
• Provisioning of enterprise hardware and a migration away from virtualized solutions.
8.4.2.2.3. Desired outcomes
• The ability to handle a high number of concurrent commits (50, with a queue of 80) given the number of
automated build and local developer desktop commits.
• The ability to manage database growth given their current usage model
• The ability to perform audits as part of their clean before check-in process
implement configuration or feature changes to improve or solve the problem.
• Optimization of the JVM - Migration of Coverity Connect to the enterprise hardware initially
failed expectations with regards to the desired commit concurrency threshold. This was due to
misconfiguration of the java_opts_post in the cim.properties file. Due to the instability
observed in the initial testing, commits were performed using the rcp1 protocol. The initial target
was for 16 concurrent commits given dedicated application server with 32Gb of RAM. After
apply the JVM settings, this was achieved and further configuration changes were applied to the
commitPoolThreads parameter to a maximum of 50 (still using the less efficient rcp1). The
organization then performed their tests using rcp2 with the expectation that there would be modest
performance improvements in commit as well.
• The processing load on the centralized Coverity Connect server was 400-450 commits/day 4 days a
week. There was a less significant load on the central Coverity Connect instance the other 3 days of
the week. This resulted in a database with a size of approximately 175Gb (managed with snapshot
deletion) and a projected yearly usage of 350Gb.
• System response is measured by making http calls against the login page. Initially, this call took
more than 70+ seconds in the production environment. This varied significantly from the development
environment (8-9 seconds). It was determined that the significant number of snapshot deletions was
responsible as these operations significantly impacted the statistics of critical application tables. As a
result, disk-based sorts were being performed in the production database which, in turn, affected login
performance. Initially, a REINDEX was used to fix the table statistics, but continued production level
146
usage degraded this response check back to sub-optimal responsiveness. The solution was to remove
the LOC license check from the login page with a hotfix which reduced the optimal 8-9 second login
time down to 0.3 seconds.
• Once the database statistics on heavily modified tables was determined to be the root cause of
performance degradation, periodic CLUSTER operations where performed on the top 20 tables with
significant statistics drift (actual tuples versus what was reported in the stats). The CLUSTER operation
rebuilds an existing table in index order (in this case, using the primary key). This reduced sub-optimal
commit times (which averaged 18-20 minutes) down to 6-8 minutes. The down-side of resorting to
using CLUSTER is that it requires an exclusive table lock. This means that there is the possibility of
data contention between the database and the application when this operation is executing. In addition,
rebuilding certain tables (such as the xrefs) is prohibitively expensive due to the size of the table (500M
rows).
• Given the lack of availability of the commit preview feature in the Coverity Connect version that
was originally deployed, migration to 6.5.x was performed. Unoptimized, the upgrade completed
in approximately 46 hours. Configuration of the events environment variables brought this down to
approximately 9 hours.
8.4.2.2.5. Hardware
The environment consists of 3 separate systems - Production, Standby, and Development. Each system
consists of both an application server and a standalone PostgreSQL database. High-availability in the
form of Warm StandyBy [http://www.postgresql.org/docs/8.4/static/warm-standby.html] using WAL
shipping. The Development environment is used solely for testing Coverity Connect release testing to
ensure that unstable builds are not pushed out to production.
The database and application server hardware only differ in the amount of RAM available (32Gb for the
application server and 64GB for the database server) and cores (12 for the application server and 16 for
the database)
Hardware configuration:
Build hardware:
• CPU: Intel Xeon E5-26xx CPU (6 to 8 cores per CPU)
• Memory: 32/64GB RAM
• Hard Drives: 15K SAS (6gpbs) 300GB
• RAID Controller: HP P420i/Software RAID 10 (8 spindles/4 pairs)
• Rack Size:
8.4.2.2.6. Custom Coverity Connect configuration and tuning settings
The following system parameters are set for optimal performance.
147
• java_opts_post=-server -Xms24g -Xmx24g
In postgresql.conf:
• shared_buffers = 32GB
• work_mem = 4GB
• maintenance_work_mem = 4GB
• effective_io_concurrency = 8
• wal_buffers = 32MB
• checkpoint_segments = 128
• archive_mode = on
• archive_command = "scp %p standby_machine:/arch/wal/%f'
• archive_timeout = 300
• effective_cache_size = 128GB
All kernel optimizations for standalone database have been implemented with the exception of those
which target SSDs (as they are using RAID with standard HDs). No WAL isolation at the file system level.
In cov-admin-db.vmoptions:
• -Xmx48g
• -Xms48g
• -XX:+UseConcMarkSweepGC
• -Xlog:gc*=info:file=<coverity_product_install_root>/logs/gc_upgrade_%t_
%p.log:utctime,uptime,tags,level:filecount=2,filesize=50M
Upgrade environment variables
• DB_UPGRADE_EVENTS_LATEST_BATCH=64000
• DB_UPGRADE_EVENTS_NON_LATEST_BATCH=2000000
8.4.2.2.7. Notes
• 1 hr SLA (Service Level Agreement) for high-availability/uptime for Coverity Connect
• The organization has a replicated warm standby system for production. This involves a standby
Coverity Connect application server and backing database both of which are for dedicated use.
Standby application/database hardware resources are complete duplicates of their production
148
counterparts. WAL replication between the production and standby database is accomplished through
an scp script with a drift of approximately 5 minutes.
• A daily 2 hour maintenance window is used to perform CLUSTER operations on the 20 most modified
tables. The CLUSTER operation rebuilds a table in index order (using the primary key), but requires
an exclusive lock which has the potential to interfere with the running application. As they have design
centers located globally, this is a high risk operation, but yields significant performance gains.
8.4.2.2.8. Future considerations
• The use of Purge Snapshot Details in newer Coverity Connect releases. This would allow the
organization to manage database growth through the supported mechanism instead of using the
snapshot deletion mechanism (which is not ideal, as it was designed to manage mistakes, not
database size).
• The use of the Commit Preview option in newer Coverity Connect releases would also reduce the
amount of commits required as the existing clean before check in validation process only requires a
commit if new defects are introduced. This would also allow the organization to implement auditing of
commits which currently is not possible due to the snapshot deletion process to control the database
size.
8.4.3. Scenario 3: Increasing performance over time

8.4.3.1. Goals
The overall goals for the optimization of this organization's Coverity product deployment are as follows:
1. Primary goal - Improvement of Coverity Connect UI performance
2. Primary goal - Scale with regards to a large number of disparate projects (different code bases)
8.4.3.1.1. Issues and challenges
• The objective of this group is to improve the usability of the Coverity Connect UI for the purposes of
triaging defects.
• Initially a mixed deployment of Defect Manager version 4.5 instances and Coverity Integrity Manager
version 5.5.3. Migration was performed to unify the projects to the same version of Coverity Connect
with subsequent updates to major releases (6.0.x/6.5.x). The organization encountered upgrade issues
in the form of "Out of Memory" exceptions.
• number of Coverity users - 1300 / 500 active (logged in in the last year) / daily usage 3-15 users.
• number of lines of code - 260M LOC total / average 500K LOC with 225-250 active projects.
• Count fixed defects - estimate value provided by the Coverity analysis.
• Each Coverity Connect instance is on a dedicated-use server
149
• Coverity Connect is deployed with an embedded PostgreSQL database.
• The deployment is in a non-virtualized environment.
• Limited commit load as analysis submissions are limited to once per day. The average project commits
once per week. However, given the long history of some projects, database size was beginning to
impact UI responsiveness.
8.4.3.2.1. Coverity tools workflow
• Projects are built remotely, and the intermediate directory compressed and submitted for analysis and
triage.
• The submitted project is placed into a processing queue.
• Analysis is performed locally with an email notification regarding new defects being sent when analysis
has completed.
• Sufficient resources for the optimization process (see Section 8.4.3.2.5, “Hardware configuration:”).
8.4.3.2.3. Desired outcomes
• Improved user experience of the Coverity Connect UI.
implementation configuration or feature changes to improve or solve the problem.
• Login and defect selection were seen when system usage increased. Enabling JMX logging showed
that heap was approaching 12GB of the initial 16Gb of RAM which could force contention with the
embedded PostgreSQL processes. Additional RAM was added to both the coordinator and subscriber
machines (32Gb). Optimizations to the Coverity Connect configuration files were applied.
• Snapshot deletion was not used to manage growing DB. Instead, the environment was upgraded to a
newer release of Coverity Connect which supported the snapshot purge functionality (Purge Snapshot
Details). Data had accumulated from 2006 to the present; most of that data is no longer relevant. A
policy was put in place to purge anything older than 365 days. This reduced the database size from
110GB reduced to 72GB. The operation took approximate 2.5 days. No space savings was realized
initially until a backup/restore was performed.
• Coverity Connect clustering was introduced to help scale for demand in terms of new projects (with a
majority of the projects have disparate source code bases) with an ideal target of having 150 projects
per machine. The environment was configured with the coordinator and a single subscriber. Both
machines were hosted in the same locale and connected through a local 1GbE network. The initial
150
synchronization took 4-5 hours with ongoing synchronization taking between 1-10 minutes (depending
on the amount of information to synchronize).
8.4.3.2.5. Hardware configuration:
• Memory: 32GB RAM
• Hard Drives: 2TB SATA (for Coverity Connect installation) and 4X146GB SAS (for Database - SAS
Disk has been setup as RAID level 10)
• RAID Controller: HP P420i/Software RAID 10 (8 spindles/4 pairs)
8.4.3.2.6. Custom Coverity Connect configuration and tuning settings
The following system parameters are set for optimal performance.
• java_opts_post=-server -Xms24g -Xmx24g
In postgresql.conf:
• shared_buffers = 8GB
• work_mem = 256MB
• maintenance_work_mem = 512MB
• wal_buffers = 16MB
• checkpoint_segments = 64
• effective_cache_size = 16GB
In cov-admin-db.vmoptions:
• -Xms16g
• -Xmx16g
• -XX:+UseCompressedOops
• -XX:+UseConcMarkSweepGC
• -XX:+DisableExplicitGC
• -XX:NewSize=2g
• -XX:SurvivorRatio=16
• -Dcom.sun.management.jmxremote
• -Dcom.sun.management.jmxremote.port=8999
151
• -Dcom.sun.management.jmxremote.ssl=false
• -Dcom.sun.management.jmxremote.authenticate=false
8.4.3.2.7. Notes
• Remote JMX logging imposes a marginal performance penalty. Due to the low load generated in this
use case, the penalty was acceptable, but it is generally not recommended to have this enabled unless
the organization is troubleshooting application issues, or has measured the capacity on a system and
determined that there are sufficient resources.
8.4.3.2.8. Future considerations
• Use of cov-admin-db.vmoptions for upgrades. Given the amount of RAM available on the
systems, the environmental variable values could be increased to improve the performance of
upgrades.
• This use case is not entirely representative of the Coverity Connect Clustering model, because the
coordinator and subscriber are not geographically distributed. In this case, clustering is used to simply
load balance requests as very few projects require the synchronization of distributed triage stores.
152
Appendix A. Coverity Glossary
Table of Contents
Glossary ....................................................................................................................................... 153
Glossary
A
Abstract Syntax Tree (AST) A tree-shaped data structure that represents the structure of concrete
input syntax (from source code).
action In Coverity Connect, a customizable attribute used to triage a CID.

Default values are Undecided, Fix Required, Fix Submitted, Modeling
Required, and Ignore. Alternative custom values are possible.
Acyclic Path Count The number of execution paths in a function, with loops counted one
time at most. The following assumptions are also made:
• continue breaks out of a loop.
• while and for loops are executed exactly 0 or 1 time.
• do…while loops are executed exactly once.
• goto statements which go to an earlier source location are treated as

an exit.
Acyclic (Statement-only) Path Count adds the following assumptions:
• Paths within expressions are not counted.
• Multiple case labels at the same statement are counted as a single

case.
advanced triage In Coverity Connect, streams that are associated with the same triage
store always share the same triage data and history. For example,
if Stream A and Stream B are associated with Triage Store 1, and both
streams contain CID 123, the streams will share the triage values (such
as a shared Bug classification or a Fix Required action) for that CID,
regardless of whether the streams belong to the same project.
Advanced triage allows you to select one or more triage stores to update
when triaging a CID in a Coverity Connect project. Triage store selection
is possible only if the following conditions are true:
• Some streams in the project are associated with one triage store (for
example, TS1), and other streams in the project are associated with
153
Coverity Glossary
another triage store (for example, TS2). In this case, some streams
that are associated with TS1 must contain the CID that you are
triaging, and some streams that are associated with TS2 must contain
that CID.
• You have permission to triage issues in more than one of these triage
stores.
In some cases, advanced triage can result in CIDs with issue attributes
that are in the Various state in Coverity Connect.
See also, triage.
annotation For C/C++, a comment with specific syntax in the source code that
suppresses a false positive or enhances a function.
For Java, the standard Java annotation format is supported for this
purpose.
Attributes to suppress false positives are not implemented for C#

checkers.
See also code annotation and function annotation.
C
call graph A graph in which functions are nodes, and the edges are the calls
between the functions.
category See issue category.
checker A coded set of criteria to identify specific issues in your source code. As
Coverity Analysis traverses paths in your source code, it runs checkers
in order to find issues in that source. Examples of checkers include
RACE_CONDITION, RESOURCE_LEAK, and INFINITE_LOOP. For
details about checkers, see Coverity 2019.09 Checker Reference.
checker category See issue category.
churn A measure of change in defect reporting between two Coverity Analysis

releases that are separated by one minor release, for example, 6.5.0 and
6.6.0.
CID (Coverity identifier) See Coverity identification (CID).
classification A category that is assigned to a software issue in the database. Built-

in classification values are Unclassified, Pending, False Positive,
Intentional, and Bug. For Test Advisor issues, classifications include
Untested, No Test Needed, and Tested Elsewhere. Issues that are
154
Coverity Glossary
classified as Unclassified, Pending, and Bug are regarded as software

issues for the purpose of defect density calculations.
code annotation For C/C++, an annotation that suppresses a false positive. The analysis
engine ignores events that are preceded by a code annotation, and
defects that are caused by ignored events have the Intentional status
in the Coverity Connect unless overridden. See also annotation and
function annotation.
For Java, the standard Java annotation format is supported for this
purpose.
Attributes to suppress false positives are not implemented for C#

checkers.
code base A set of related source files.
code coverage The amount of code that is tested as a percentage of the total amount
of code. Code coverage is measured different ways: line coverage, path
coverage, statement coverage, decision coverage, condition coverage,
and others.
component A named grouping of source code files. Components allow developers

to view only issues in the source files for which they are responsible,
for example. In Coverity Connect, these files are specified by a Posix
regular expression. See also, component map.
component map Describes how to map source code files, and the issues contained in the
source files, into components.
control flow graph A graph in which blocks of code without any jumps or jump targets are
nodes, and the directed edges are the jumps in the control flow between
the blocks. The entry block is where control enters the graph, and the
exit block is where the control flow leaves.
Coverity identifier (CID) An identification number assigned to a software issue. A snapshot

contains issue instances (or occurrences), which take place on a specific
code path in a specific version of a file. Issue instances, both within a
snapshot and across snapshots (even in different streams), are grouped
together according to similarity, with the intent that two issues are
"similar" if the same source code change would fix them both. These
groups of similar issues are given a numeric identifier, the CID. Coverity
Connect associates triage data, such as classification, action, and
severity, with the CID (rather than with an individual issue).
CWE (Common Weakness A community-developed list of software weaknesses, each of which is

Enumeration) assigned a number (for example, see CWE-476 at http://cwe.mitre.org/
data/definitions/476.html ). Coverity associates many categories of
defects (such as "Null pointer dereferences") with a CWE number.
155
Coverity Glossary
Coverity Connect A Web application that allows developers and managers to identify,
manage, and fix issues found by Coverity analysis and third-party tools.
D
data directory The directory that contains the Coverity Connect database. After
analysis, the cov-commit-defects command stores defects in this
directory. You can use Coverity Connect to view the defects in this
directory. See also intermediate directory.
deadcode Code that cannot possibly be executed regardless of what input values
are provided to the program.
defect See issue.
deterministic A characteristic of a function or algorithm that, when given the same

input, will always give the same output.
dismissed issue Issue marked by developers as Intentional or False Positive in the Triage
pane. When such issues are no longer present in the latest snapshot of
the code base, they are identified as absent dismissed.
domain A combination of the language that is being analyzed and the type of
analysis, either static or dynamic.
dynamic analysis Analysis of software code by executing the compiled program. See also
static analysis.
dynamic analysis agent A JVM agent for Dynamic Analysis that instruments your program to
gather runtime evidence of defects.
dynamic analysis stream A sequential collection of snapshots, which each contain all of the issues
that Dynamic Analysis reports during a single invocation of the Dynamic
Analysis broker.
E
event In Coverity Connect, a software issue is composed of one or more
events found by the analysis. Events are useful in illuminating the
context of the issue. See also issue.
F
false negative A defect in the source code that is not found by Coverity Analysis.
false path pruning (FPP) A technique to ensure that defects are only detected on feasible paths.
For example, if a particular path through a method ensures that a given
condition is known to be true, then the else branch of an if statement
156
Coverity Glossary
which tests that condition cannot be reached on that path. Any defects
found in the else branch would be impossible because they are “on a
false path”. Such defects are suppressed by a false path pruner.
false positive A potential defect that is identified by Coverity Analysis, but that you
decide is not a defect. In Coverity Connect, you can dismiss such issues
as false positives. You might also use annotations (also called code
annotations) in your source code to identify such issues as intentional
during the source code analysis phase, prior to sending analysis results
to Coverity Connect.
fixed issue Issue from the previous snapshot that is not in the latest snapshot.
fixpoint The Extend SDK engine notices that the second and subsequent paths
through the loop are not significantly different from the first iteration, and
stops analyzing the loop. This condition is called a fixpoint of the loop.
flow-insensitive analysis A checker that is stateless. The abstract syntax trees are not visited in
any particular order.
function annotation An annotation that enhances or suppresses a function model. See also
annotation and code annotation.
function model A model of a function that is not in the code base that enhances the
intermediate representation of the code base that Coverity Analysis uses
to more accurately analyze defects.
I
impact Term that is intended to indicate the likely urgency of fixing the issue,
primarily considering its consequences for software quality and security,
but also taking into account the accuracy of the checker. Impact
is necessarily probabilistic and subjective, so one should not rely
exclusively on it for prioritization.
inspected issue Issue that has been triaged or fixed by developers.
intermediate directory A directory that is specified with the --dir option to many commands.
The main function of this directory is to write build and analysis results
before they are committed to the Coverity Connect database as a
snapshot. Other more specialized commands that support the --dir
option also write data to or read data from this directory.
The intermediate representation of the build is stored in

<intermediate_directory>/emit directory, while the analysis
results are stored in <intermediate_directory>/output. This
directory can contain builds and analysis results for multiple languages.
See also data directory.
157
Coverity Glossary
intermediate representation The output of the Coverity compiler, which Coverity Analysis uses to run
its analysis and check for defects. The intermediate representation of the
code is in the intermediate directory.
interprocedural analysis An analysis for defects based on the interaction between functions.
Coverity Analysis uses call graphs to perform this type of analysis. See
also intraprocedural analysis.
intraprocedural analysis An analysis for defects within a single procedure or function, as opposed
to interprocedural analysis.
issue Coverity Connect displays three types of software issues: quality

defects, potential security vulnerabilities, and test policy violations. Some
checkers find both quality defects and potential security vulnerabilities,
while others focus primarily on one type of issue or another. The Quality,
Security, and Test Advisor dashboards in Coverity Connect provide high-
level metrics on each type of issue.
Note that this glossary includes additional entries for the various types of
issues, for example, an inspected issue, issue category, and so on.
issue category A string used to describe the nature of a software issue; sometimes
called a "checker category" or simply a "category." The issue pertains
to a subcategory of software issue that a checker can report within the
context of a given domain.
Examples:
• Memory - corruptions
• Incorrect expression
• Integer overflow Insecure data handling
Impact tables in the Coverity 2019.09 Checker Reference list issues

found by checkers according to their category and other associated
checker properties.
K
killpath For Coverity Analysis for C/C++, a path in a function that aborts program
execution. See <install_dir_sa>/library/generic/common/
killpath.c for the functions that are modeled in the system.
For Coverity Analysis for Java, and similarly for C# and Visual Basic,
a modeling primitive used to indicate that execution terminates at this
point, which prevents the analysis from continuing down this execution
path. It can be used to model a native method that kills the process, like
System.exit, or to specifically identify an execution path as invalid.
158
Coverity Glossary
kind A string that indicates whether software issues found by a given checker
pertain to SECURITY (for security issues), QUALITY (for quality issues),
TEST (for issues with developer tests, which are found by Test Advisor),
or QUALITY/SECURITY. Some checkers can report quality and security
issues. The Coverity Connect UI can use this property to filter and
display CIDs.
L
latest state A CID's state in the latest snapshot merged with its state from previous
snapshots starting with the snapshot in which its state was 'New'.
local analysis Interprocedural analysis on a subset of the code base with Coverity
Desktop plugins, in contrast to one with Coverity Analysis, which usually
takes place on a remote server.
local effect A string serving as a generic event message that explains why the
checker reported a defect. The message is based on a subcategory of
software issues that the checker can detect. Such strings appear in the
Coverity Connect triage pane for a given CID.
Examples:
• May result in a security violation.
• There may be a null pointer exception, or else the

comparison against null is unnecessary.
long description A string that provides an extended description of a software issue

(compare with type). The long description appears in the Coverity
Connect triage pane for a given CID. In Coverity Connect, this
description is followed by a link to a corresponding CWE, if available.
Examples:
• The called function is unsafe for security related

code.
• All paths that lead to this null pointer comparison

already dereference the pointer earlier (CWE-476).
M
model For Coverity Analysis for C/C++, a representation of each method in the
application that is used for interprocedural analysis, created as each
function is analyzed. For example, the model shows which arguments
are dereferenced, and whether the function returns a null value.
For Coverity Analysis for Java, and similarly for C#, a representation of
each method in the application that is used for interprocedural analysis.
159
Coverity Glossary
For example, the model shows which arguments are dereferenced, and
whether the function returns a null value. Models are created as each
function is analyzed.
modeling primitive A modeling primitive is used when writing custom models. Each
modeling primitive is a function stub: It does not specify any executable
code, but when it is used in a custom model, the modeling primitive
instructs a checker how to analyze (or refrain from analyzing) the
function being modeled.
For example, the C/C++ checker CHECKED_RETURN

is associated with the modeling primitive
__coverity_always_check_return__(). This primitive tells
CHECKED_RETURN to verify that the function being analyzed really
does return a value.
Some modeling primitives are generic, but most are specific to a

particular checker or group of checkers. The set of available modeling
primitives varies from language to language.
N
native build The normal build process in a software development environment that
does not involve Coverity products.
O
outstanding issue Issues that are uninspected and unresolved.
owner User name of the user to whom an issue has been assigned in Coverity
Connect. Coverity Connect identifies the owner of issues not yet
assigned to a user as Unassigned.
P
postorder traversal The recursive visiting of children of a given node in order, and then the
visit to the node itself. Left sides of assignments are evaluated after
the assignment because the left side becomes the value of the entire
assignment expression.
primitive In the Java language, elemental data types such as strings and integers
are known as primitive types. (In the C-language family, such types are
typically known as basic types).
For the function stubs that can be used when constructing custom
models, see modeling primitive.
project In Coverity Connect, a specified set of related streams that provide a

comprehensive view of issues in a code base.
160
Coverity Glossary
R
resolved issues Issues that have been fixed or marked by developers as Intentional or
False Positive through the Coverity Connect Triage pane.
run In Prevent releases 4.5.x or lower, a grouping of defects committed to

the Coverity Connect. Each time defects are inserted into the Coverity
Connect using the cov-commit-defects command, a new run is
created, and the run ID is reported. See also snapshot
S
sanitize To clean or validate tainted data to ensure that the data is valid.
Sanitizing tainted data is an important aspect of secure coding practices
to eliminate system crashes, corruption, escalation of privileges, or
denial of service. See also tainted data.
severity In Coverity Connect, a customizable property that can be assigned

to CIDs. Default values are Unspecified, Major, Moderate, and Minor.
Severities are generally used to specify how critical a defect is.
sink Coverity Analysis for C/C++: Any operation or function that must
be protected from tainted data. Examples are array subscripting,
system(), malloc().
Coverity Analysis for Java: Any operation or function that must be

protected from tainted data. Examples are array subscripting and the
JDBC API Connection.execute.
snapshot A copy of the state of a code base at a certain point during development.
Snapshots help to isolate defects that developers introduce during
development.
Snapshots contain the results of an analysis. A snapshot includes both

the issue information and the source code in which the issues were
found. Coverity Connect allows you to delete a snapshot in case you
committed faulty data, or if you committed data for testing purposes.
snapshot scope Determines the snapshots from which the CID are listed using the Show
and the optional Compared To fields. The show and compare scope is
only configurable in the Settings menu in Issues:By Snapshot views and
the snapshot information pane in the Snapshots view.
source An entry point of untrusted data. Examples include environment

variables, command line arguments, incoming network data, and source
code.
static analysis Analysis of software code without executing the compiled program. See
also dynamic analysis.
161
Coverity Glossary
status Describes the state of an issue. Takes one of the following values: New,
Triaged, Dismissed, Absent Dismissed, or Fixed.
store A map from abstract syntax trees to integer values and a sequence of
events. This map can be used to implement an abstract interpreter, used
in flow-sensitive analysis.
stream A sequential collection of snapshots. Streams can thereby provide

information about software issues over time and at a particular points in
development process.
T
tainted data Any data that comes to a program as input from a user. The program
does not have control over the values of the input, and so before using
this data, the program must sanitize the data to eliminate system
crashes, corruption, escalation of privileges, or denial of service. See
also sanitize.
translation unit A translation unit is the smallest unit of code that a compiler can
recompile. What the unit is depends primarily on the language; for
example, a Java translation unit is a single source file, while a C or C+
+ translation unit is a source file plus all the other files (such as libraries)
that the source file includes.
When Coverity tools capture code to analyze, that capture is a collection

of translation units. This collection includes the source files used to
generate object code, along with those other files and information that
form the context of the compilation. For example, in Java this context
includes bytecode files in the class path; in C or C++ this context
includes both platform information about the compiler, and defined
preprocessor directives.
triage The process of setting the states of an issue in a particular stream, or of

issues that occur in multiple streams. These user-defined states reflect
items such as how severe the issue is, if it is an expected result (false
positive), the action that should be taken for the issue, to whom the issue
is assigned, and so forth. These details provide tracking information for
your product. Coverity Connect provides a mechanism for you to update
this information for individual and multiple issues that exist across one or
more streams.
See also advanced triage.
triage store A repository for the current and historical triage values of CIDs. In
Coverity Connect, each stream must be associated with a single triage
store so that users can triage issues (instances of CIDs) found in the
streams. Advanced triage allows you to select one or more triage stores
to update when triaging a CID in a Coverity Connect project.
162
Coverity Glossary
See also advanced triage.
type A string that typically provides a short description of the root cause
or potential effect of a software issue. The description pertains to a
subcategory of software issues that the checker can find within the
scope of a given domain. Such strings appear at the top of the Coverity
Connect triage pane, next to the CID that is associated with the issue.
Compare with long description.
Examples:
The called function is unsafe for security related code
Dereference before null check
Out-of-bounds access
Evaluation order violation
Impact tables in the Coverity 2019.09 Checker Reference list issues

found by checkers according to their type and other associated checker
properties.
U
unified issue An issue that is identical and present in multiple streams. Each instance
of an identical, unified issue shares the same CID.
uninspected issues Issues that are as yet unclassified in Coverity Connect because they
have not been triaged by developers.
unresolved issues Defects are marked by developers as Pending or Bug through the
Coverity Connect Triage pane. Coverity Connect sometimes refers to
these issues as Outstanding issues.
V
various Coverity Connect uses the term Various in two cases:
• When a checker is categorized as both a quality and a security

checker. For example, USE_AFTER_FREE and UNINIT are listed as
such in the Issue Kind column of the View pane. For details, see the
Coverity 2019.09 Checker Reference.
• When different instances of the same CID are triaged differently.

Within the scope of a project, instances of a given CID that occur in
separate streams can have different values for a given triage attribute
if the streams are associated with different triage stores . For
example, you might use advanced triage to classify a CID as a Bug in
163
Coverity Glossary
one triage store but retain the default Unclassified setting for the CID
in another store. In such a case, the View pane of Coverity Connect
identifies the project-wide classification of the CID as Various.
Note that if all streams share a single triage store, you will never
encounter a CID in this triage state.
view Saved searches for Coverity Connect data in a given project. Typically,
these searches are filtered. Coverity Connect displays this output in
data tables (located in the Coverity Connect View pane). The columns in
these tables can include CIDs, files, snapshots, checker names, dates,
and many other types of data.
164
Appendix B. Legal Notice
Table of Contents
B.1. Legal Notice .......................................................................................................................... 165
B.1. Legal Notice

The information contained in this document, and the Licensed Product provided by Synopsys, are the
proprietary and confidential information of Synopsys, Inc. and its affiliates and licensors, and are supplied
subject to, and may be used only by Synopsys customers in accordance with the terms and conditions
of a license agreement previously accepted by Synopsys and that customer. Synopsys' current standard
end user license terms and conditions are contained in the cov_EULM files located at <install_dir>/
doc/en/licenses/end_user_license.
Portions of the product described in this documentation use third-party material. Notices, terms and
conditions, and copyrights regarding third party material may be found in the <install_dir>/doc/en/
licenses directory.
Customer acknowledges that the use of Synopsys Licensed Products may be enabled by authorization
keys supplied by Synopsys for a limited licensed period. At the end of this period, the authorization
key will expire. You agree not to take any action to work around or override these license restrictions
or use the Licensed Products beyond the licensed period. Any attempt to do so will be considered an
infringement of intellectual property rights that may be subject to legal action.
If Synopsys has authorized you, either in this documentation or pursuant to a separate mutually accepted
license agreement, to distribute Java source that contains Synopsys annotations, then your distribution
should include Synopsys' analysis_install_dir/library/annotations.jar to ensure a clean
compilation. This annotations.jar file contains proprietary intellectual property owned by Synopsys.
Synopsys customers with a valid license to Synopsys' Licensed Products are permitted to distribute this
JAR file with source that has been analyzed by Synopsys' Licensed Products consistent with the terms of
such valid license issued by Synopsys. Any authorized distribution must include the following copyright
notice: Copyright © 2019 Synopsys, Inc. All rights reserved worldwide.
U.S. GOVERNMENT RESTRICTED RIGHTS: The Software and associated documentation are provided
with Restricted Rights. Use, duplication, or disclosure by the U.S. Government is subject to restrictions
set forth in subparagraph (c)(1) of The Rights in Technical Data and Computer Software clause at
DFARS 252.227-7013 or subparagraphs (c)(1) and (2) of Commercial Computer Software – Restricted
Rights at 48 CFR 52.227-19, as applicable.
The Manufacturer is: Synopsys, Inc. 690 E. Middlefield Road, Mountain View, California 94043.
The Licensed Product known as Coverity is protected by multiple patents and patents pending, including
U.S. Patent No. 7,340,726.
Trademark Statement
Coverity and the Coverity logo are trademarks or registered trademarks of Synopsys, Inc. in the
U.S. and other countries. Synopsys' trademarks may be used publicly only with permission from
165
Legal Notice
Synopsys. Fair use of Synopsys' trademarks in advertising and promotion of Synopsys' Licensed
Products requires proper acknowledgement.
Microsoft, Visual Studio, and Visual C# are trademarks or registered trademarks of Microsoft Corporation
in the United States and/or other countries.
Microsoft Research Detours Package, Version 3.0.
Copyright © Microsoft Corporation. All rights reserved.
Oracle and Java are registered trademarks of Oracle and/or affiliates. Other names may be trademarks of
their respective owners.
"MISRA", "MISRA C" and the MISRA triangle logo are registered trademarks of MISRA Ltd, held on
behalf of the MISRA Consortium. © MIRA Ltd, 1998 - 2013. All rights reserved. The name FindBugs and
the FindBugs logo are trademarked by The University of Maryland.
Other names and brands may be claimed as the property of others.
This Licensed Product contains open source or community source software ("Open Source Software")
provided under separate license terms (the "Open Source License Terms"), as described in the
applicable license agreement under which this Licensed Product is licensed ("Agreement"). The
applicable Open Source License Terms are identified in a directory named licenses provided with the
delivery of this Licensed Product. For all Open Source Software subject to the terms of an LGPL license,
Customer may contact Synopsys at [email protected] and Synopsys
will comply with the terms of the LGPL by delivering to Customer the applicable requested Open Source
Software package, and any modifications to such Open Source Software package, in source format,
under the applicable LGPL license. Any Open Source Software subject to the terms and conditions of the
GPLv3 license as its Open Source License Terms that is provided with this Licensed Product is provided
as a mere aggregation of GPL code with Synopsys' proprietary code, pursuant to Section 5 of GPLv3.
Such Open Source Software is a self-contained program separate and apart from the Synopsys code
that does not interact with the Synopsys proprietary code. Accordingly, the GPL code and the Synopsys
proprietary code that make up this Licensed Product co-exist on the same media, but do not operate
together. Customer may contact Synopsys at [email protected] and
Synopsys will comply with the terms of the GPL by delivering to Customer the applicable requested
Open Source Software package in source code format, in accordance with the terms and conditions of
the GPLv3 license. No Synopsys proprietary code that Synopsys chooses to provide to Customer will
be provided in source code form; it will be provided in executable form only. Any Customer changes
to the Licensed Product (including the Open Source Software) will void all Synopsys obligations under
the Agreement, including but not limited to warranty, maintenance services and infringement indemnity
obligations.
The Cobertura package, licensed under the GPLv2, has been modified as of release 7.0.3. The
package is a self-contained program, separate and apart from Synopsys code that does not interact
with the Synopsys proprietary code. The Cobertura package and the Synopsys proprietary code
co-exist on the same media, but do not operate together. Customer may contact Synopsys at
[email protected] and Synopsys will comply with the terms of the
GPL by delivering to Customer the applicable requested open source package in source format, under
the GPLv2 license. Any Synopsys proprietary code that Synopsys chooses to provide to Customer
upon its request will be provided in object form only. Any changes to the Licensed Product will void all
166
Legal Notice
Coverity obligations under the Agreement, including but not limited to warranty, maintenance services
and infringement indemnity obligations. If Customer does not have the modified Cobertura package,
Synopsys recommends to use the JaCoCo package instead.
For information about using JaCoCo, see the description for cov-build --java-coverage in the
Command Reference.
LLVM/Clang subproject
Copyright © All rights reserved. Developed by: LLVM Team, University of Illinois at Urbana-
Champaign (http://llvm.org/). Permission is hereby granted, free of charge, to any person
obtaining a copy of LLVM/Clang and associated documentation files ("Clang"), to deal with Clang
without restriction, including without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of Clang, and to permit persons to whom Clang is furnished
to do so, subject to the following conditions: Redistributions of source code must retain the above
copyright notice, this list of conditions and the following disclaimers. Redistributions in binary form
must reproduce the above copyright notice, this list of conditions and the following disclaimers in
the documentation and/or other materials provided with the distribution. Neither the name of the
University of Illinois at Urbana-Champaign, nor the names of its contributors may be used to endorse
or promote products derived from Clang without specific prior written permission.
CLANG IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH CLANG OR THE USE OR OTHER DEALINGS WITH
CLANG.
Rackspace Threading Library (2.0)

Copyright © Rackspace, US Inc. All rights reserved. Licensed under the Apache License, Version 2.0
(the "License"); you may not use these files except in compliance with the License. You may obtain a
copy of the License at http://www.apache.org/licenses/LICENSE-2.0.
Unless required by applicable law or agreed to in writing, software distributed under the License is
distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
express or implied. See the License for the specific language governing permissions and limitations
under the License.
SIL Open Font Library subproject

Copyright © 2019 Synopsys Inc. All rights reserved worldwide. (www.synopsys.com), with
Reserved Font Name fa-gear, fa-info-circle, fa-question.
This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is
available with a FAQ at http://scripts.sil.org/OFL.
Apache Software License, Version 1.1

Copyright © 1999-2003 The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
167
Legal Notice
1. Redistributions of source code must retain the above copyright notice, this list of conditions and
the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or other materials provided with the distribution.
3. The end-user documentation included with the redistribution, if any, must include the following
acknowlegement: "This product includes software developed by the Apache Software Foundation
(http://www.apache.org/)."
Alternately, this acknowlegement may appear in the software itself, if and wherever such third-
party acknowlegements normally appear.
4. The names "The Jakarta Project", "Commons", and "Apache Software Foundation" must not be
used to endorse or promote products derived from this software without prior written permission.
For written permission, please contact [email protected].
5. Products derived from this software may not be called "Apache" nor may "Apache" appear in their
names without prior written permission of the Apache Group.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Apache License Version 2.0, January 2004 http://www.apache.org/licenses/

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in
compliance with the License. You may obtain a copy of the License at: http://www.apache.org/
licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is
distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
express or implied. See the License for the specific language governing permissions and limitations
under the License.
Results of analysis from Coverity and Test Advisor represent the results of analysis as of the date and
time that the analysis was conducted. The results represent an assessment of the errors, weaknesses
and vulnerabilities that can be detected by the analysis, and do not state or infer that no other errors,
weaknesses or vulnerabilities exist in the software analyzed. Synopsys does NOT guarantee that all
errors, weakness or vulnerabilities will be discovered or detected or that such errors, weaknesses or
vulnerabilities are are discoverable or detectable.
SYNOPSYS AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, CONDITIONS AND

REPRESENTATIONS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING THOSE RELATED
168
Legal Notice
TO MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, SATISFACTORY QUALITY,

ACCURACY OR COMPLETENESS OF RESULTS, CONFORMANCE WITH DESCRIPTION, AND
NON-INFRINGEMENT. SYNOPSYS AND ITS SUPPLIERS SPECIFICALLY DISCLAIM ALL IMPLIED
WARRANTIES, CONDITIONS AND REPRESENTATIONS ARISING OUT OF COURSE OF DEALING,
USAGE OR TRADE.
169

Cov Deploy Install Guide

Uploaded by

Copyright:

Available Formats

Cov Deploy Install Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cov Deploy Install Guide

Uploaded by

Copyright:

Available Formats

Coverity 2019.

09 Installation and Deployment Guide :

1. Coverity product overview

Coverity Analysis Installation

• Coverity Analysis (formerly called Coverity Static Analysis)

• Coverity Extend SDK supports the development of custom checkers.

• Coverity Platform Installation

2. Installation and deployment overview

components, Chapter 3, Installing Coverity Desktop components, Chapter 4, Installing Architecture

2.1. Deployment planning

Understanding the Coverity system architecture

Installing Coverity products

Database and system tuning

Deployment scenario analysis

Bring into production

Monitoring the system

System enhancements and upgrades

• Coverity Policy Manager

1.1. Installing Coverity Connect

Before installing to a production environment:

• It is important to understand deployment considerations and hardware recommendations described in

• Desired installation directory.

• Location of your Coverity Connect license file.

• Desired ports for Coverity Connect communications.

• External PostgreSQL credentials (if not using the embedded database).

• Amount of available RAM (for embedded database performance).

To install Coverity Connect:

4. Run the installer script or program for your operating system:

5. Complete the installation process:

b. Select the Fresh Installation option.

c. Enter the destination directory for the installation.

d. Enter the location of the Coverity license file (license.dat).

e. Choose the database type for Coverity Connect.

• PostgreSQL server name

h. Select your Coverity Connect database performance tuning option.

i. (Windows only) Choose whether or not to create Start Menu entries.

j. Choose and confirm the Coverity Connect administrator password.

k. (Windows only) Choose to run Coverity Platform as a service.

l. Choose the host name configuration.

Choose from the host name of your machine, or the IP address.

m. Enter the HTTP port number.

n. Configure the following ports:

• The Tomcat configuration files located at:

For example, see commitPort in cim.properties.

7. Check your installation:

c. Review Section 1.4, “Post-installation notes”.

To uninstall Coverity Platform:

2. On Linux, run the uninstall script.

1.2. Coverity Platform installation modes

1.2.1. Selecting an installation mode

To specify an installer mode:

• Console mode: Use the command-line option -c for console mode.

• Graphical mode: Use the -g option for graphical mode.

For example, to start the graphical installer on Linux:

1.2.2. Coverity Platform graphical installer

1.2.3. Coverity Connect silent installer

Installer command line options

Do not use the -V prefix with these options:

• 2 - Backup and restore