Coverity® 6.6 Deployment Guide - pudn.comread.pudn.com/downloads575/ebook/2361365/cov... · 4....
Transcript of Coverity® 6.6 Deployment Guide - pudn.comread.pudn.com/downloads575/ebook/2361365/cov... · 4....
Coverity® 6.6 Deployment Guide
Planning, Installation,Tuning, and Supported PlatformsGuidance for Coverity Analysis, Coverity Platform, and Coverity Desktop.
Copyright © 2004-2013 Coverity, Inc. All rights reserved worldwide.
Table of ContentsAbout this guide .................................................................................................................. v
1. Coverity product overview ......................................................................................... v2. How this guide is organized ....................................................................................... vi
1. Deployment planning ........................................................................................................ 11.1. Deployment options ............................................................................................... 3
1.1.1. Deployment Checklist .................................................................................. 31.1.2. How Coverity products integrate into a build system .......................................... 51.1.3. Coverity Analysis deployment models ............................................................. 61.1.4. Coverity Connect deployment options ............................................................. 71.1.5. Other deployment models and features ........................................................... 11
1.2. Hardware recommendations for your deployment ....................................................... 131.2.1. Coverity Connect hardware deployment recommendations ................................ 131.2.2. Coverity Analysis hardware recommendations ................................................. 14
2. Installation ................................................................................................................... 152.1. Coverity installer modes ........................................................................................ 16
2.1.1. Coverity Connect silent installer ................................................................... 162.2. Installing Coverity Platform ................................................................................... 20
2.2.1. Coverity Connect software requirements ........................................................ 202.2.2. Software no longer supported ....................................................................... 202.2.3. Compatibility with other Coverity modules ..................................................... 212.2.4. Installing Coverity Platform components ........................................................ 212.2.5. Advanced installation options ....................................................................... 252.2.6. Coverity Platform post-installation notes ........................................................ 282.2.7. Stopping and starting Coverity Connect ......................................................... 29
2.3. Installing Coverity Analysis ................................................................................... 302.3.1. Coverity Analysis License Options ................................................................ 31
2.4. Installing Coverity Desktop .................................................................................... 382.4.1. Installing Coverity Desktop for Eclipse, Wind River WorkBench, and QNXMomentics ........................................................................................................ 382.4.2. Installing Coverity Desktop for Microsoft Visual Studio .................................... 422.4.3. Installing Coverity Analysis for local analysis ................................................. 43
2.5. Troubleshooting for FLEXnet licensing .................................................................... 443. Coverity Connect system tuning, maintenance, and monitoring ................................................ 52
3.1. Post-installation - what's next? ................................................................................ 533.1.1. cov-analysis configuration and set-up ........................................................... 533.1.2. cov-platform system configuration and set-up ................................................. 533.1.3. The Coverity Deployment Maturity Model ..................................................... 54
3.2. Coverity Connect system and database tuning ............................................................ 553.2.1. PostgreSQL database tuning - embedded database ........................................... 553.2.2. Tuning shared memory settings ................................................................... 573.2.3. JVM settings ............................................................................................ 58
3.3. Monitoring and diagnosing Coverity Connect performance .......................................... 603.3.1. Linux monitoring and diagnosis tools ............................................................ 603.3.2. Windows monitoring and diagnosis tools ........................................................ 613.3.3. Solaris monitoring tools .............................................................................. 63
3.4. Maintaining and backing up the Coverity Connect database ......................................... 643.4.1. Maintaining the size of your database ............................................................ 643.4.2. Backing up the database .............................................................................. 653.4.3. System performance reference ..................................................................... 65
3.5. Deployment Scenarios .......................................................................................... 683.5.1. Scenario 1: Increasing the number of concurrent commits ................................. 68
iii
3.5.2. Scenario 2: Optimal performance for commits, application performance, and UIresponse ........................................................................................................... 713.5.3. Scenario 3: Increasing performance over time ................................................. 76
4. Supported Platforms ........................................................................................................ 804.1. Coverity Connect and Coverity Policy Manager Platforms ........................................... 814.2. Coverity Analysis and Coverity Dynamic Analysis ..................................................... 82
4.2.1. Supported platforms ................................................................................... 824.2.2. Supported Compilers: Coverity Analysis for Java and Coverity Dynamic Analysis....................................................................................................................... 834.2.3. Supported Compilers: Coverity Analysis for C/C++ ......................................... 84
4.3. Coverity Test Advisor SCM and platform support ....................................................... 904.3.1. Coverity Test Advisor for C/C++ .................................................................. 904.3.2. Coverity Test Advisor for Java ...................................................................... 91
4.4. Coverity Security Advisor for Java framework and technology support ........................... 934.5. Architecture Analysis ............................................................................................ 944.6. Coverity Desktop® ............................................................................................... 96
4.6.1. Coverity Desktop® for Eclipse on supported platforms ..................................... 964.6.2. Coverity Desktop® for IBM Rational Team Concert (RTC) on supportedplatforms .......................................................................................................... 964.6.3. Coverity Desktop® for ARM Development Studio 5 (DS-5) on supportedplatforms .......................................................................................................... 964.6.4. Coverity Desktop® for Wind River WorkBench on supported platforms ............... 974.6.5. Coverity Desktop® for Microsoft's Visual Studio IDE on supportedplatforms .......................................................................................................... 974.6.6. Coverity Desktop® for QNX Momentics IDE on supported platforms ................. 97
A. Appendix ..................................................................................................................... 99A.1. Coverity Glossary ................................................................................................ 99A.2. Coverity Legal Notice ......................................................................................... 107
iv
Coverity® 6.6 Deployment Guide
About this guideThe Coverity® 6.6 Deployment Guide contains information to help you plan for a Coverity productdeployment. This guide is intended for system architects, deployment architects, and build engineers whoare responsible for the planning and installation of Coverity tools.
Product functionality, configuration, and operation instructions that are not related to deployment are notcovered in this manual, so it is assumed that you have a knowledge of Coverity products and features. Formore detailed information about Coverity tools, refer to the following documentation:
• Coverity® Platform 6.6 Usage and Administration Guide - Guidance for system administrators and endusers of Coverity Connect, Coverity Policy Manager, and Coverity Integrity Report.
• Coverity® Analysis 6.6 Administration Guide - Guidance for build engineers or system architects tointegrate and configure cov-analysis tools with the nightly build system.
The complete documentation set for Coverity products can be found under the root installation directoryof 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. Thefollowing figure shows the relationship of issues found by Coverity tools (and third-party analyses) to theCoverity components that help you manage and fix them.
Coverity Analysis Installation
Coverity Analysis components and extensions are built on top of Coverity® SAVE Static AnalysisVerification Engine (Coverity SAVE), the set of foundational technologies that support the use of Coveritycheckers to detect quality defects (Quality Advisor issues), potential security vulnerabilities (CoveritySecurity Advisor issues), test violations (Test Advisor issues), and Java runtime defects (Coverity DynamicAnalysis issues).
• Analysis Components
• Coverity Analysis (formerly called Coverity Static Analysis)
v
• Coverity Dynamic Analysis
• Architecture Analysis
• Analysis Extensions
• Coverity Third Party Integration Toolkit supports the addition of issues found by third-party productsto the Coverity Connect database.
• Coverity Compiler Integration Toolkit allows you to extend the set of compilers that can be used tobuild 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 analysesand 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 SAVE to support localanalyses.
• Coverity Connect is a Web-based application that helps software developers and team leads manageand fix issues found through Coverity analyses and third party tools. The Coverity Connect interfaceprovides descriptions of the issues found by Coverity analyses and shows where the issues exist inthe source code.
• Downloads: Coverity Connect also provides access to downloads for Coverity Integrity Reportand the Coverity Desktop plugins for Eclipse and Visual Studio.
• Extensions: Coverity Connect also provides access to the WSDL files for the Configuration andDefect services of the Coverity Platform Web Services API.
• Coverity Policy Manager is a Web-based solution for code governance that enables softwaredevelopment 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 leaderswith cross-organizational responsibilities the insight needed to better align quality goals with businessobjectives, to enforce standards across the development organization, and to manage third-party codedependencies.
2. How this guide is organized
There are four Parts to this guide:
1. Deployment planning represents the research and planning phase of the overall deployment. This sectionprovides information to help you identify your organization's needs.
2. Installation in which you work from specifications and plans created during deployment planning phaseto install the Coverity tools.
3. Coverity Connect system tuning, maintenance, and monitoring provides recommendations for systemtuning and database maintenance procedures to ensure optimal performance. In addition, this sectionalso provides tips for monitoring your system so that you can collect trend data to track the performanceof your system over time.
vi
About this guide
4. Supported Platforms is a matrix Coverity products, compiler, and component and the supported operatingsystems and runtime environments.
Coverity deployment follows a process of planning, designing, and implementing the Coverity tools. Thefollowing diagram shows the deployment cycle and the cycle's phases that are discussed in this guide:
2.1. Deployment planning
Deployment planning is a critical step to successfully implement Coverity tools. Each organization has itsown 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 ina system that might under-perform, be difficult to maintain, be too expensive to operate, could wasteresources, or could be unable to scale to meet your organization's increasing needs.
Understanding the Coverity system architectureDuring this step, you review the system deployment options to understand how Coverity productsintegrate with your existing build system, and choose the hardware infrastructure so that your deployedsystem runs efficiently and quickly. For more information, see Chapter 1.1, Deployment options [p. 3].
Hardware specificationsThis section provides hardware recommendations to implement your hardware infrastructure on whichCoverity products will run.
2.2. Implementation
During the implementation phase of the deployment cycle, you work from specifications and plans createdduring the deployment planning phase to build and test the deployment, ultimately rolling out the deploymentinto production.
Hardware setupThe implementation of the hardware that will host the Coverity deployment.
Pre-installation configurationThere are several decisions to make before you install the Coverity products, including the platformand file system settings you wish to use. For more information, see ???.
vii
About this guide
Installing Coverity productsThe process of installing the Coverity products based on the decisions that you made during thedeployment planning phase. For installation instructions, see Part 2, “Installation ” [p. 15].
Database and system tuningTuning the database and system settings for Coverity Connect. For more information, see Chapter 3.2,Coverity Connect system and database tuning [p. 55].
Deployment scenario analysisThis section provides deployment use cases that describe the steps and decisions that Coverity customershave made to successfully integrate Coverity products into their system. You can review these usecases to apply some the solutions to your deployment planning. For more information, see Chapter 3.5,Deployment Scenarios [p. 68]
Bring into productionGet the system up and running so that all components are functioning together (also see "SystemConfiguration" below).
2.3. Operation
The Operating phase consists of post-deployment tasks to configure, maintain, and monitor yourorganization's Coverity deployment.
System configurationThe "What's Next" list provides an overview of tasks that you need to complete in order to set up yoursystem (mainly administrative tasks).
System maintenanceSystem maintenance provides recommendation for you to enable features and settings that will maintainthe size of the Coverity Connect database.
Monitoring the systemMonitoring the system is an important part of the process. It is suggested that you record trend dataover time so you can make sure that the entire system is performing optimally. Guidelines for monitoringare provided in Chapter 3.3, Monitoring and diagnosing Coverity Connect performance [p. 60].
System enhancements and upgradesThis step represents the on-going improvement to the deployment, through upgrading new versionsand implementing new features.
viii
About this guide
Part 1. Deployment planning
1.1. Deployment options ....................................................................................................... 31.1.1. Deployment Checklist .......................................................................................... 31.1.2. How Coverity products integrate into a build system .................................................. 51.1.3. Coverity Analysis deployment models ..................................................................... 61.1.4. Coverity Connect deployment options ..................................................................... 71.1.5. Other deployment models and features ................................................................... 11
1.2. Hardware recommendations for your deployment ............................................................... 131.2.1. Coverity Connect hardware deployment recommendations ........................................ 131.2.2. Coverity Analysis hardware recommendations ......................................................... 14
2
Chapter 1.1. Deployment options
The following sections provide information that will help you make decisions about deployment for yourorganization for the present -- with goal of planning for future growth.
After you read this section, you will find it useful to read the Chapter 3.5, Deployment Scenarios [p. 68]so you can see a practical implementation of Coverity tools.
1.1.1. Deployment Checklist
The deployment checklist is a list of questions that help you make decisions about how you will deployCoverity products (for example, which deployment models you will choose) and what hardware you willchoose.
When you are thinking about how you will deploy the tools it is important recognize that one of the largestcontributing factors to the performance of your system is based on system load. System load consists ofthe following:
• Number of concurrent commits from Coverity Analysis to Coverity Connect - Commits represent theact of sending and processing the Coverity Analysis analysis results and defect data from the intermediatedirectory to Coverity Connect. The number of and size of your commits can require a lot of hardwareresources. The number of commits also increases the size of the database that Coverity Connect uses tostore this information.
The basic criteria for commit load is the number issue instances that are committed per unit of time.This is determined by a number of factors including the number of codes bases, the size of each codebase, the number of branches and configurations per code base, and how many of the code bases willbe analyzed and how frequently.
• Number of concurrent users of Coverity Connect - The number of concurrent users on a Coverity Connectsystem can affect the performance of the user interface.
• Number of concurrent Coverity Connect Web Services API calls - The Web Services API allows youwrite Web applications that communicate with Coverity Connect. The number of concurrent WebServices 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 suchuse both concurrent web services API calls and concurrent commits (although the size of the commitstend to be much smaller than in a central build).
Table 1.1.1. Deployment checklist
More informationResults/notesDeployment considerations
Questions regarding your organization's products
Consult the Supported platforms section of this guideto determine operating systems, versions, andrequired patches for Coverity products.
What platforms do you develop andbuild on?
The number of products can determine the numberof streams you that you commit, thereby impactingthe commit load.
How many products do you have inyour organization?
Targets are for a given product can determine thenumber of streams you that you commit, therebyimpacting the commit load.
How many targets are typically builtfor each product?
3
More informationResults/notesDeployment considerations
How many lines of code are in yourproduct?
Questions regarding your organization's build process
Are builds made on demand or integrated as part ofan automated process?
When will a build be generated
The frequency of the builds in relation to the analysisintegration contributes to commit load, and thus
How frequently are builds initiated?
affects the way you plan for your hardwaredeployment. For more information, see Chapter 1.2,Hardware recommendations for yourdeployment [p. 13].
What is the number of concurrentCoverity Analysis commits?
Is it through a CI tool (such as Jenkins)? SeeSection 1.1.5.2, “Coverity Jenkins plug-in” [p. 12].
How is the build command invoked?
See the deployment descriptions for the desktopoption.
Do your developers develop onIDEs?
Questions regarding your organization's development process
How many organizations or businessunits are using Coverity products?
The number of concurrent users will impact theperformance of your system, particularly the Coverity
How many developers are there ineach organization or business unit?
Connect UI. Because of this, it is important to havean accurate number of users. Coverity has a list ofmaximum limits to help ensure optimumperformance. If the number of users for yourorganization exceeds the limits, you could considerimplementing one Coverity Connect deploymenttype over another.
How developers in your organization distributedgeographically? Do you want developers in other
How are your developers distributedgeographically?
organizations to access a given Coverity Connectinstance? You could consider implementing aCoverity Connect clustered environment.
See the clean before check-in model.Do you have a "clean beforecheck-in" policy?
See Section 1.1.5.3, “Export issues” [p. 12].Do you use a bug-tracking system?
See Section 3.4.2, “Backing up the database” [p. 65].Do you have established standardback-up procedures?
See Chapter 3.3, Monitoring and diagnosing CoverityConnect performance [p. 60].
Do you have a system validation andmonitoring plan?
See Section 3.1.3, “The Coverity DeploymentMaturity Model” [p. 54].
Do you plan on using the Coveritydeployment maturity model?
4
Deployment options
1.1.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 areintegrated into a typical build environment.
It is important to recognize the various deployment options and recommendations so that you can makedecisions about the hardware to which you will install and implement Coverity components. After youhave identified how you want to deploy your Coverity system, you should use the hardware recommendationchapter of this manual to set up your environment.
This section begins with a diagram and explanation of a basic build system. The subsequent deploymentfigures in the section below build upon the basic to show how Coverity tools are integrated into a buildsystem.
Note
Note that for the diagrams that depict Coverity deployments, the dotted lines represent featuresor tools that are optional.
The following image shows a high-level view of a basic build system:
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 controlmanagement (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 foundin the software.
7. The developer fixes the assigned bugs. The process repeats.
5
Deployment options
1.1.3. Coverity Analysis deployment models
The Coverity analysis tools are installed as part of the Coverity® Analysis installation package and thegoal of these tools is to find issues in your code:
Software organizations generally produce several products, and each product tends to consist of a numberof related code branches and targets. These branches and targets might be for the various supportedplatforms, product versions, trunk and development branches. Coverity Analysis runs over each code baseto produce a snapshot of each code base. A snapshot consists of the results of running Coverity Analysisonce over a code base. The snapshot includes both the issue information and the version of the source codein which the defects were found and is committed to Coverity Connect after the analysis process iscompleted.
As your developers continue to modify their code bases, it is useful to provide them with on-going dataabout the creation of new issues and the elimination of existing ones. Administrators can define streamsfor each specific code base that they wish to analyze. A stream is a sequence of snapshots over a specifiedcode base. Each time Coverity Analysis runs, the analysis results are grouped with previous results thatare made up of the same code base and configuration. Streams capture issue information and trends overtime. For more information, see the Coverity® Platform 6.6 Usage and Administration Guide).
For specific implementation details (including how to configure compilers, integrate with the build, enablecheckers and so forth), see the Coverity® Analysis 6.6 Administration Guide.
Note
Hardware considerations for the analysis tools are generally established by the needs of yourorganization's build server (performance, size, and so forth.) However, there are some sizingoptions to consider. For more information, see Section 1.2.2, “ Coverity Analysis hardwarerecommendations” [p. 14].
1.1.3.1. Central build deployment model
Build engineers typically write scripts that automatically run Coverity Analysis on the source repositoryat some scheduled interval (typically nightly). They can also allow developers to subscribe to automaticallyreceive email notifications of new issues in their source files. Developers triage and annotate the defectswithin Coverity Connect or Coverity Desktop. The central build model introduces the least amount ofchange to the development process and provides a strict separation between developer and build engineertasks. A developer interacts with Coverity Analysis by adding or modifying source files in the coderepository and viewing issue results in Coverity Connect. A build engineer writes scripts to check out thesource 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
6
Deployment options
build engineer can integrate Coverity Analysis with the build process to automatically provide CoverityAnalysis consumers with fresh snapshots each morning or at another desired interval.
1.1.3.2. Desktop deployment model (local analysis)
This deployment model, which adds to the central Coverity Analysis build model, allows developers togenerate Coverity Analysis snapshots of their own code. Although this model introduces complexity toconfiguration and administration, it allows developers to analyze code at their desktop, and fix defectsbefore checking in their source code changes to the repository. In this way, the developers can ensure thatthe code is clean before they check it in to the central repository.
In general, the central build provides more thorough inter-procedural analysis than a desktop build becausethe central build includes more of the source code. In the desktop model, a developer gets rapid feedback.However, this model requires greater understanding of the use and operation of Coverity Analysis. Manycompanies choose to establish the central build model, then allow individual developers to gradually adopta desktop model.
Coverity provides a desktop solution with Coverity Desktop, which is a plug-in to the Eclipse, Wind RiverWorkBench, or Visual Studio IDEs. Coverity Desktop allows you to perform an analysis of your code, aswell as viewing and triaging the issues found by the analysis within the IDE.
1.1.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, canview the issues in the source code, classify the issues, and so forth. There are many more powerful featuresin Coverity Connect; that you can implement to help you locate and fix issues, as well as tracking andcharting your organization's projects. For more information about Coverity Connect features, see theCoverity® Platform 6.6 Usage and Administration Guide.
7
Deployment options
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 subscriberinstances. At least one (stand alone or otherwise) Coverity Connect instance is required.
1.1.4.1. Coverity Connect stand-alone deployments
In this model, Coverity Connect is deployed as a standalone application. Users within your organizationwill log in to and access a central instance of Coverity Connect. There can be multiple instances of CoverityConnect in your organization, but issue data, classification states (triage), and trending metrics are notshared among the individual instances (for information about deploying Coverity Connect as a sharedenvironment, see Section 1.1.4.2, “Coverity Connect clustered deployment model ” [p. 9]). CoverityConnect 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 wellas user and system components.
In a standalone environment, Coverity Connect can be installed either with an embedded or externalPostgreSQL database:
8
Deployment options
Coverity Connect server with an embedded database. Installs the Coverity Connect application serverand the PostgreSQL database at the same time and on the same machine. This option is generally used forits ease of use. It is the default option during installation is and is useful for getting the system up andrunning quickly. It also might be a good alternative for organizations that do not have a dedicated DatabaseAdministrator.
Coverity Connect server with an external database. Allows you to install the Coverity Connectapplication server in one location, and associate it with a separately installed PostgreSQL database. Thebenefits to using an external database are:
• You can maintain and scale the PostgreSQL database separately. For example, you have finer controlof 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 Large, Medium (default), or Demoperformance tuning option. The installer will inform you if your current system settings are not properlyconfigured. If this occurs, you will have to adjust your system settings in order for Coverity Connect torun. For more information, see Chapter 2.2, Installing Coverity Platform [p. 20].
Coverity Connect installs PostgreSQL 8.4 for all new installations.
Both of the standalone deployment options are subject to system limits. So, it is recommended that youdetermine the load on your system using the deployment checklist and then reference your results with theCoverity Connect deployment limits table. If you think that your system might exceed theses limits, youmight to consider deploying Coverity Connect in a clustered environment.
1.1.4.2. Coverity Connect clustered deployment model
The Coverity Connect clustered deployment model allows you to deploy clusters of Coverity Connectinstances on which centrally managed data is synchronized in an enterprise. Importantly, developer-settriage states can be updated automatically across the cluster. For Coverity Connect to synchronize data, itis necessary to set up one instance of Coverity Connect as the central Coordinator and to configure otherCoverity 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 propagatesto other members of the cluster. In this way, the Coordinator is responsible for synchronizing triage dataupdates across Coverity Connect Subscribers.
9
Deployment options
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 specifichardware for the clustered components (for example, clustered components that will accept larger commitloads might have a different hardware configuration than those with lesser commits.)
• The number of Coverity Connect users can be distrusted along the environment so as to not limitperformance. For example, if the number of users on the system exceeds the numbers recommended inthe recommended maximum limits for a stand-alone system, you can set up a clustered environmentoffset the performance load.
• If you have users in separate geographic locations, you can set up subscribers for any number of localesand still share issue information.
• Clustered components can be set with either embedded or external databases.
For more information about how the data is synchronized and to set up a clustered environment, seeCoverity® Platform 6.6 Usage and Administration Guide.
1.1.4.3. Recommended maximum limits in Coverity Connect
Coverity recommends the following boundary limits to ensure that Coverity Connect runs properly anddoes not experience performance degradation. It is important to estimate for these limits, the results mayaffect the way you deploy Coverity Connect and the hardware you choose for the deployment. To estimatethe limits in your organization, see the Section 1.1.1, “Deployment Checklist” [p. 3].
See the Glossary [p. 99] for basic definitions of the items described below.
You should not exceed any of the following:
Table 1.1.2. Coverity Connect maximum settings
Maximum numberSystem item
1000Streams
1000Projects
10
Deployment options
Maximum numberSystem item
1000 - This number should be much smaller than the number of streams(1 is ideal).
Triage stores
20,000Users
100User Groups
100Component maps
100Components per component map
100Defects per source file
10,000Number of lines per source file
600 GBDatabase size
20Custom RBAC roles
1.1.5. Other deployment models and features
The following diagram represents additional (and optimal) deployment considerations that can add valueto the developers and administrator of you system.
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 Reportto 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.
11
Deployment options
1.1.5.1. Clean before check-in
The clean before check-in model is way to verify that your code is "clean" before it is checked in to yoursource control management (SCM) system. Before you commit the defects you can run a command lineexecutable to produce a Commit Preview Report. This report (in JSON format) shows the current state ofthe 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 definedby Coverity. (Although, Coverity does offer the Deployment Maturity Model -- a Professional Servicesprogram to bring your deployment to be "Coverity Clean." See Section 3.1.3, “The Coverity DeploymentMaturity Model” [p. 54].) 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 werefound after a given analysis.
1.1.5.2. Coverity Jenkins plug-in
The Coverity plug-in for Jenkins makes it easy to add invocations of Coverity tools to an existing automatedbuild 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/.
1.1.5.3. Export issues
Coverity Connect allows you to export an Coverity Analysis issue into a file that can be imported into athird-party bug tracking system. This is accomplished by enabling the Export button in the Triage pane inthe Coverity Connect user interface. To enable the Export button, you must create and install a utilityprogram to automatically handle the exported file.
For more information, see the Coverity® Platform 6.6 Usage and Administration Guide.
12
Deployment options
Chapter 1.2. Hardware recommendations for your deployment
1.2.1. Coverity Connect hardware deployment recommendations
The tables in this section list Coverity-recommended hardware configurations for Coverity Platformdeployments. The first table lists the minimum hardware recommendations so that Coverity Platform willrun without major performance degradation. The second table lists optimal hardware recommendations.
Note that these are recommendations and are not necessarily hardware requirements.
These hardware recommendations specify the following Coverity Connect deployment options:
• Coverity Connect with an embedded database - Common Coverity Platform deployment. This includesthe PostgreSQL database and the Coverity Connect application installed on the same server.
• Coverity Connect with an external database - The Coverity Connect server uses an external PostgreSQLdatabase. For more information, see Section 2.2.5.1, “Using an external PostgreSQL database withCoverity Connect” [p. 25].
Table 1.2.1. Minimum hardware deployment recommendations
Storage deviceMin.storage size
RAMCPUServer/Database
SSDa or HDDb.240GB8GB DDR31066Mhz
Intel XeonWestmere-EX
Embeddeddatabase
series or AMDequivalent
SSDaa or HDDbb240GB4GB DDR31066Mhz
Intel XeonWestmere-EX
Externaldatabase
series or AMDequivalent
aRecommend that TRIM be enabled.b7200 rpm recommended.
Table 1.2.2. Optimal hardware deployment recommendations
Storage deviceMin.storage size
RAMCPUServer
SSDa or HDDb.512GB+32GBDDR31066Mhz
Intel Xeon E5Sandy Bridge-EPseries or AMDequivalent
Embeddeddatabase
SSDaa or HDDbb240GB+32GBDDR31066Mhz
Intel Xeon E3Sandy Bridge seriesor AMD equivalent
Externaldatabase
aRecommend that TRIM be enabled.b7200 rpm recommended.
Note
• The minimum number of CPU cores is 4 with a minimum CPU speed of 2.0Ghz.
13
• RAM should be 32GB+ as a starting point. For existing Coverity Connect databases, the RAMshould be no less than 15% of the total database size.
• Virtualized environments are not recommended for optimal 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.
1.2.2. Coverity Analysis hardware recommendations
Prior to running a parallel analysis, you need to make sure that you have the appropriate hardware andenough free memory for each worker that you start:
• You need one CPU core per worker that you run. For example, to run six workers, you need six CPUcores.
• You can use the following formula to estimate the minimum amount of memory that you are likely toneed (noting that more memory is safer, but less might work, especially for code bases smaller than 1million LOC):
• When running only quality checkers:
1.0 GB + (0.5 GB * number of workers)
For example, for an analysis that is not running any Web application security checkers:
To run six workers, you need 4 GB (= 1 + (0.5 * 6)) of free memory. For eight workers,you need 5 GB (= 1 + (0.5 * 8)).
• When running Web application security checkers (with or without quality checkers), use the followingformula to help determine the minimum:
1.0 GB + (0.5 GB * number of workers) + (3 GB per million LOC)
Minimum memory requirements:
1.5GB (only if result <= 1.5 GB), else the result of this formula.
For example, to run six workers when using a Java web application security checkeron a 500,000 line code base (0.5 million LOC), you need 5.5 GB (= 1.0 GB+ 0.5 GB * 6 + 0.5 million LOC * 3 GB = 1 GB + 3 GB +1.5 GB). However, if your result <= 1.5 GB, you still need 1.5 GB.
Note
Parallel analysis increases the speed of quality analysis only. It does not affect the speed ofthe Web application security analysis.
14
Hardware recommendations for your deployment
Part 2. InstallationThis part is for administrators who install Coverity® Analysis, Coverity® Platform, and Coverity® Desktop. Afterthe installation process is complete, you can find post-installation deployment configuration, and system and databasetuning details and in the chapters that follow for the products that you installed.
Note
For upgrade instructions are covered in a separate document. These sections only pertain to new installationinstances. For upgrade instructions, see the Coverity® 6.6 Upgrade and Release Notes.
Tip
Before you install any of the Coverity products, it is recommended that you or your database administratorchoose 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 befound in PostgreSQL 9.0 High Performance authored by Gregory Smith and published by Packt Publishing.
Chapter 2.1. Coverity installer modes
For both of the Coverity Platform and Coverity Analysis installers, you can specify a either a graphical orconsole (command-line) interface.
On Linux-based systems, the console mode (with text-based prompts) is the default, and on Windowssystems graphical mode is the default.
To specify an installer mode, use the command-line option -c for console mode, or -g for graphical mode.
To start the graphical installer, use the -g option. For example, on Linux:
cov-platform-linux64-6.6.0.sh -g
On Windows, when using the command prompt, you must precede the command with a start /waitcommand. Additionally, if the executable filename contains spaces, you must include empty, double quoteseven 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-6.6.0.exe -c
2.1.1. Coverity Connect silent installer
The Coverity Connect silent installer allows you to specify all of the installation configuration details onthe 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, you specify the installation utility with the -q option, followed by the installationparameters. The -q option and the installation parameters must all be on the same command line.Additionally, all of the installation parameters must be prefixed by -V, with the exception of the --dirparameter. The following example installs a "large" Coverity Platform deployment with an embeddeddatabase.
bin/cov-platform-linux64-*.sh -q \-Vadmin.password=coverity \-Vlicense.agreement=i.agree.to.the.license \-Vlicense.dat=/tmp/license.dat \-Vdb.type=embedded \-Vhttp.port=14800 \-Vcommit.port=14801 \-Vcontrol.port=14802 \-Vdb.embedded.port=14803 \-Vinternal.db.embedded.settings=Large \-dir cim/install
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 CoverityConnect with an embedded database. If you use any of the following parameters, you should providespecifically assigned values. Some values, if left blank, will accept the default value, but this is not arecommended practice. For more information about the installation options, see Chapter 2.2, InstallingCoverity Platform [p. 20].
Installer command line optionsThe following options are required on the command line. Do no use the -V prefix with these options:
16
DescriptionOption
Enable the silent installer.-q
The location to which Coverity Platform will be installed.--dir <directory>
Password, location, and upgrade parameters
DescriptionParamater
The administrator password that youwill use to log into Coverity Connectafter it is installed.
admin.password=<password>
Agree to the terms of the Coverityproduct license.
license.agreement=i.agree.to.the.license
Specify the full directory path to thelicense file. The license.dat
license.dat=<path>
filename must be included at the endof the path.
Specify this option if you are upgradingan installed instance of Coverity
db.embedded.confirm.upgrade=true
Connect. IMPORTANT: See theCoverity® 6.6 Upgrade and ReleaseNotes for important upgradeinformation and procedures before yourun the upgrade process.
Database type parameters
DescriptionParameter
Specifies the type of database that will be used with the Coverity Connectapplication server. embedded specifies Coverity Connect with embedded
db.type=[embedded| postgres}
PostgreSQL database. postgres specifies that Coverity Connect will connectto an existing, external PostgreSQL database. Note the following:
• If you specify embedded, you must include the Embedded databaseparameters on the command line.
• If you specify postrges, you must include the External database parameterson the command line. The external database must be created before you runthe installer. For more information, see Section 2.2.5, “Advanced installationoptions” [p. 25].
Embedded database parametersThese options set the parameters for installing Coverity Connect with an embedded PostgreSQLdatabase. The installer will automatically install and configure a PostreSQL database version 8.4.17.
DescriptionParameter
Specify the embedded database port.db.embedded.port=<databse_port_number>
Enter the full path of the directory to whichthe database files will be installed. If you
db.embedded.datadir=<path>
do not enter this option, the database
17
Coverity installer modes
DescriptionParameter
directory defaults to<install_dir_cp>/database
External database parametersThese options set the parameters for installing Coverity Connect with an external PostgreSQL database.Coverity Connect supports PostgreSQL version 8.4 through 9.2, however due to an issue withPostgreSQL, it is possible to encounter serious performance degradation impacting commits whenrun against PostgreSQL versions 9.1.x and 9.2.x. This issue has no current workaround/tuning tomitigate, so it is recommended to use, or revert to, PostgreSQL version 8.4.17 as an external CoverityConnect database.
DescriptionParameter
Specify the hostname of the external PostgreSQLdatabase.
db.host=<host_name>
Specify the port number of the external PostgreSQLdatabase.
db.port=<port_number>
Specify the name of the external PostgreSQLdatabase.
db.database=<name_of_database>
Specify the name of the administrative user thatcreated the external PostgreSQL database.
db.login=<user_name>
Specify the administrative password of the externalPostgreSQL database.
db.password=<database_password>:
Service parameter
DescriptionParameter
Specify that Coverity Connect will be enabled as a Windows service.This parameter is optional and will not affect any installations onnon-Windows platforms.
service.enable=true
Coverity Connect port parameters
DescriptionParameters
Specify the HTTP port number for Coverity Connect.http.port=<port>
Specify the Coverity Connect commit port.commit.port=<port>
Specify the port used by the embedded application server for internalserver communication.
control.port=<port>
Optional - Specify that Coverity Connect should use SSL (HTTPS)communication. The HTTPS protocol requires an installed servercertificate from a certificate authority.
accept.https=true
Specify the HTTPS port number.https.port=<port>
18
Coverity installer modes
Enable purge snapshot parameter
DescriptionParameter
Optional - Enable Coverity Connect to automatically configure and schedulea clean-up utility that removes older snapshot information to reduce the sizeof the database.
s13n.enable=true
Embedded database tuning parameters
DescriptionParameter
Required for embedded databases. Select yourCoverity Connect database performance tuning
internal.db.embedded.settings=[Demo| Medium | Large]
option. For more information, see Step4.g [p. 23].
19
Coverity installer modes
Chapter 2.2. Installing Coverity Platform
Coverity Platform is the name of the installer that installs and upgrades Coverity Connect and CoverityPolicy Manager, which is now installed as part of Coverity Connect. The procedures for new (fresh)installations are covered in this chapter. Upgrade procedures are described in the Coverity® 6.6 Upgradeand Release Notes.
After you install Coverity Platform, your IDE users can download and install Coverity Desktop for Eclipse,Wind River WorkBench, and Visual Studio from the Downloads link in Coverity Connect. Users can alsogain access to Coverity Integrity Report from that link.
For the most part, this section refers to installing Coverity Connect, as the other components are installedas part of, or are accessible though Coverity Connect. The installer is referred to as Coverity Platform, andthe installation directory is referred to as <install_dir_cp>.
2.2.1. Coverity Connect software requirements
Coverity Connect requires the following software on the client side:
• Firefox 5 or later, Internet Explorer 8 or 9, Google Chrome 7 (and later), or Safari 5.1.5 (and later).
• JavaScript enabled
• Display resolution of at least 1024 x 768 pixels recommended
The Coverity Connect server is bundled with the following software:
• Apache Tomcat 6.0.20
• PostgreSQL 8.4.2
• Sun JRE 1.7.0_17 1
2.2.2. Software no longer supported
Dropped Support NoticeThe following are no longer supported:
• PostgreSQL 8.1 and 8.2
• PostgreSQL 8.3 (as an external database)
• Windows 32-bit platforms
• Linux 32-bit platforms
• Solaris x86 32-bit platforms
• Internet Explorer 7
• Coverity Connect Web Services API versions v1 and v2.
1Coverity Connect and related processes such as the cov-manage-im command use the Oracle Java SE Runtime Environment 7 (JRE-7). ForJRE-7, Coverity platform support depends on the support statement by Oracle. cov-analysis commands, however, use JRE 1.6.0_21, with theexception of Java security analyses (Coverity Security Advisor analyses) and FindBugs™ analyses (through Coverity Analysis for Java) which useJRE-7.
20
2.2.3. Compatibility with other Coverity modules
Coverity Connect 6.6 accepts analysis results from any Coverity Analysis or Coverity Dynamic Analysisversions equal or previous to 6.6. Coverity Connect also accepts analysis results from Coverity® StaticAnalysis versions 4.5.1, 4.5.0, 4.4.1, or 4.4.0.
2.2.4. Installing Coverity Platform components
The Coverity Platform installer provides the option of using a Coverity Connect database that is embeddedin the installation package, or connecting to a pre-existing external PostgreSQL database for CoverityConnect.
On Linux systems, you must not be logged as root to install Coverity Platform.
To install Coverity Platform components:
1. 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.
The build and analysis processes typically take place on separate machines, though this is not required.The machines that perform builds and analyses require Coverity® Static Analysis 4.4.1 or later.
2. If you do not plan to run Coverity Connect as a service, choose or create an operating system user aswhom the Coverity Connect server software runs.
On Windows systems that do not run Coverity Connect as a service, this is the user who can start orstop Coverity Connect.
On Linux, or on Windows systems that run Coverity Connect as a service, the Administrator or rootuser can start and stop Coverity Connect.
3. Run the installer script or program for your operating system:
Linux, 64-bitcov-platform-linux64-6.6.0.sh
Solaris x86cov-platform-solaris-x86-6.6.0.sh
Windows, 64-bitcov-platform-win64-6.6.0.exe
For Windows, double-click the .exe program.
For Linux, run the installer script in a Bourne shell, for example:
> cov-platform-linux64-6.6.0.sh
The installer uses a text-based console mode or a graphical mode. The installation choices for graphicaland console modes are equivalent.
To change the installer mode, see Chapter 2.1, Coverity installer modes [p. 16].
4. Complete the installation process:
a. Accept the license agreement.
21
Installing Coverity Platform
b. Enter the destination directory for the installation.
The destination directory should be on a local file system. In the documentation, the CoverityPlatform installation directory is referred to as <install_dir_cp>.
Note
If an earlier version of Coverity Connect is installed in the specified destination directory,the Coverity Platform will treat the installation as an upgrade and attempt to install overthe existing instance.
Do not attempt to upgrade Coverity Connect without following the procedures in theCoverity® 6.6 Upgrade and Release Notes .
c. 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, but theinstaller will not alert you if there is a problem with your license. The use of CoverityPolicy Manager and requires a special license component. For information about yourlicensing, contact Coverity inside sales at [email protected].
d. Choose your type of Coverity Connect database.
The Coverity Connect database can be an embedded database or an existing PostgreSQLinstallation.
Coverity Connect uses 8.4 as the embedded database, and supports 8.4-9.2 as the external database.This external database option is only intended for experienced PostgreSQL DBAs. For the installersettings for an external database, see Section 2.2.5.1, “Using an external PostgreSQL databasewith Coverity Connect” [p. 25].
Note
Due to an issue with PostgreSQL, it is possible that you can encounter seriousperformance degradation impacting commits when run against PostgreSQL versions9.1.x and 9.2.x. This issue has no current workaround/tuning to mitigate, so it isrecommended to use, or revert to, PostgreSQL version 8.4.17 as an external CoverityConnect database.
e. If you chose the Embedded database option, enter the Coverity Connect database port and thedatabase location.
The TCP port that the embedded database server uses to listen for connections. This is only usedfor 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 beon a local volume that has at least 2GB of free space. The default is<install_dir_cp>/database.
f. If you chose the External database option, enter the following PostgreSQL configurationparameters for the database you will use:
• PostgreSQL server name
• Database port
22
Installing Coverity Platform
• Database name
• Database user
• Database password
If you have not already done so, you must ask your database administrator (DBA) to create adatabase and user role for Coverity Connect. You (the user) must have privileges to create andalter tables in the database. For more information, see Section 2.2.5, “Advanced installationoptions” [p. 25].
g. Select your Coverity Connect database performance tuning option.
Coverity Platform will warn you if your system does not meet the RAM requirements on yoursystem and you will not be able to select that tuning option.
To help with performance, you can choose from the following options:
1. Medium - For servers that meet the minimum system requirements, which is 8GB of RAM.
2. Large - This tuning configuration is allowed to use all of the installed RAM on your system.
3. Demo - Will run on a small computer and does not require the full 8GB of recommendedRAM. You should not use this option for any production system. This options should be usedfor proof-of-concept or testing environments only.
Note
These deployment tunings do not affect RAM when installed with an external database.However, the JVM settings are set for both embedded and external databases.
If you are running the graphical installer and your shared memory settings are not set to therecommended values, they are displayed in red. It is important to change your system to therecommended settings. Furthermore, if your settings are displayed in red, Coverity Connect willnot start in any mode other than Demo mode.
For instructions about changing the JVM settings, see Section 3.2.2, “Tuning shared memorysettings ” [p. 57].
h. Choose and confirm the Coverity Connect administrator password.
This is the password for the Coverity Connect administrator (admin) account. Administratorscan use this account to log in with a web browser and configure users, create projects, and manageother administrative settings.
i. Choose the host name configuration.
Choose from the host name of your machine, or the IP address.
j. Enter the HTTP port number.
This is the port that used by the Coverity Connect server. Users connect to the HTTP port toaccess 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.
23
Installing Coverity Platform
The HTTPS protocol requires an installed server certificate from a certificate authority. If youchoose this option, you must specify the HTTPS Port number. The default is 8443.
k. Configure the following ports:
• Commit port - The port used to send data from the build and analysis processes. If you areusing a firewall, make sure it is configured to allow incoming connections on this port.Thedefault is 9090.
• Control port - The Port used by the embedded application server for internal servercommunication. The default is 8005.
l. (Windows only) Choose to run as a service.
If you have Windows Administrator privileges and want to run Coverity Connect as a service.The service runs as the built-in Windows account LocalService. You cannot change thissetting during the upgrade process.
5. If you changed any of the default ports, make a note of the port number(s) for later use, such as forthe cov-commit-defects --dataport command.
After the installation completes, a record of some of this information is also available in the followingfiles:
• <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.
6. Choose to enable Purge Snapshot Details.
This option enables Coverity Connect to automatically configure and schedule a clean-up utility thatremoves older snapshot information to reduce the size of the database. The default settings are:
• Removes snapshot information that is both:
• Older than 120 days
• Other than the five most recent snapshots
• Occurs every day at 5:00 AM
For new installations, this option is selected by default. For upgrades, this option is not selected bydefault.
To change the schedule for the snapshot purging utility, you can configure the snapshot purge settingsin the Coverity Connect UI in Configuration → System → Maintenance.
24
Installing Coverity Platform
Important upgrade information
If you are upgrading Coverity Connect and you enable this option, the initial clean-up processmight take a long time to complete, especially if you have a large database and/or you havebuild and commit processes concurrently scheduled with the clean-up process. It is importantthat you read the upgrade notes and configuration recommendations in the Coverity® Platform6.6 Usage and Administration Guide.
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 youpreviously created.
If you are using HTTPS and you open Coverity Connect in a web browser before you haveenabled the server for SSL, you will receive an error message that you do not have the correctcertificate 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 CoverityConnect to use SSL" section in the Coverity® Platform 6.6 Usage and Administration Guide.
c. Review Section 2.2.6, “Coverity Platform post-installation notes” [p. 28].
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.
The uninstall script provides an option for removing user-supplied data. If you want to retainthese files for your own purposes, you should back them up before uninstalling Coverity Connect.
2.2.5. Advanced installation options
The following installation options are available.
2.2.5.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, includingimplementing a database backup and recovery system.
Caution
This section is intended only for experienced PostgresSQL DBAs (database administrators).
25
Installing Coverity Platform
Configuring PostgreSQL for Coverity Connect
You should be familiar with the following before performing this procedure.
Prerequisites for external PostgreSQL configuration
• A working installation of PostgreSQL (version 8.4 through 9.2).
• 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 CoverityConnect. For example:
createdb -0 <role name>...
The permissions allow the installer to create the database schema and to alter or drop tables when youupgrade Coverity Connect.
For best handling of international characters, create the database with the settings --encodingUTF8 --locale C. These settings may not be available on some existing PostgreSQL installations,depending on the version, the operating system, and the options used when initially creating thedatabase 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 followthe prompts to complete the installation. The settings used by the installer for this configuration aredescribed in Table 2.2.1 [p. 26].
Table 2.2.1. External PostgresSQL Installer settings
DefaultDescriptionName
NoneUsually the host name where the PostgreSQL server runs.PostgreSQL server name
5432The TCP port on which the server is listening for connections.Database port
NoneName of the database that you previously created for use byCoverity Connect.
Database name
NoneUser name that owns the database name previously specified.Database user
NonePassword for previously specified user.Database password
26
Installing Coverity Platform
DefaultDescriptionName
Yes(Windows only) If you have Windows Administrator privilegesand want to run Coverity Connect as a service. The service runsas the built-in Windows account LocalService.
Run as service
Yes(Windows only) Opens a web browser on the URL to the CoverityConnect server.
Launch web browser
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 specifyan 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.
2.2.5.1.1. Understanding database information in the cim.properties file
In the event of difficulties connecting to an external database, you might want to examine and edit theproperty file that controls the external database configuration.
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:
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, afteryou have installed Coverity Connect with an external database, you cannot just change this valueto 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.
For example:
27
Installing Coverity Platform
#Mon Sep 14 11:13:39 PDT 2009embeddedDatabase=falsemaindb.name=jdoe_maindb.driver=org.postgresql.Driverdb.dialect=org.hibernate.dialect.PostgreSQLDialectmaindb.password=afy687maindb.user=jdoemaindb.url=jdbc\:postgresql\://t-postgres-03\:5432/jdoe_maindir.log=/usr/local/jdoe/CIM/server/base/logscommitPort=9090dir.temp=/usr/local/jdoe/CIM/server/base/temp
You must restart Coverity Connect after you add this attribute.
2.2.5.1.2. Changing the Number of Concurrent Commits
The default number of concurrent commits is limited to 5. To change this number, insert the followingproperty:
commitPoolThreads=N (where N is the number of commits)
2.2.5.1.3. Optimizing JVM utilization of additional RAM in config/system.properties
By default, the application is started with the following JVM defaults:
For Medium deployments (default):
-Xms=3840m
-Xmx=3840m
-XX:MaxPermSize=256m
For Large deployments:
-Xms=Maximum memory / 2
-Xmx=Maximum memory / 2
-XX:MaxPermSize=256m
For larger installations with numerous users/projects/snapshots and available RAM, these settings can beoptimized as follows:
java_opts_post=-server -Xms16g -Xmx16g -XX:MaxPermSize=4g2
2.2.6. Coverity Platform post-installation notes
There are some important notes to keep in mind after you install Coverity Platform:
Coverity Connect post-installation notes
After installing Coverity Connect:
• Do not move Coverity Connect from its installation location.
2Assuming a system with 64Gb of total RAM with an allocation of 50% for the JVM.
28
Installing Coverity Platform
• 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 numbersis permitted, it could cause problems when you upgrade to a new version. When you upgrade, theinstallation directory name is unmodified.
If you have to make these types of configuration changes, you should create a new installation, backupyour old system, and restore the backup into the new installation instance. See the Coverity® 6.6Upgrade and Release Notes.
2.2.7. 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 getstatus 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 unnecessarybecause Coverity Connect starts and stops automatically when the system boots up or shuts down. WhenCoverity 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 isable to use this program to start or stop it.
Note
If you need to restart your external PostgreSQL database, see thehttp://www.postgresql.org/docs/manuals/PostgreSQL documentation.
29
Installing Coverity Platform
Chapter 2.3. Installing Coverity Analysis
Coverity Analysis is a tool set that contains Coverity analysis tools that you use to analyze your C/C++,Java, or C# code bases and programs. This document guides you through the steps of running the Coverity®Analysis installer.
Some of the analysis products that you can install include:
• Coverity Coverity Analysis for C/C++, Java, and C#
As of the 6.6.0 release, Coverity Analysis is no longer available for stand-alone installation. For hardwarerecommendations, see Section 1.2.2, “ Coverity Analysis hardware recommendations” [p. 14].
• Coverity Coverity Dynamic Analysis
• Coverity Architecture Analysis
• Coverity Extend SDK
• Coverity Wizard - GUI-based configuration tool that is installed as part of Coverity Coverity Analysis.
Note
Coverity Wizard supports C/C++ and Java only.
Certain Coverity Analysis products are only available for certain platforms. So, depending on the platformon to which you are installing, you might only be able to access a subset of the analysis tools. For a list ofplatform availability, see Section 2.3.1, “Coverity Analysis License Options” [p. 31].
2.3.1. Coverity Analysis License Options
Coverity Analysis licenses have options that enable or disable functionality in Coverity Analysis and itsinfrastructure. Any combination of the following options can be enabled:
• TESTQuality analysis (C/C++,Java and C#).
• Java Web application security analysis.
• Test analysis.
• Coverity Third Party Integration Toolkit usage.
These options are provided through both of the Coverity Analysis licensing mechanisms: Coverity Analysislicenses and FLEXnet licenses.
For more information about the licenses packages available refer to the license overview.
Pre-6.5 licenses continue to be supported for backward compatibility. They do not have the optionsmentioned above. When Coverity Analysis 6.5 sees a pre-6.5 license, it infers that quality analysis isenabled and the other three options are disabled. Therefore, you don’t need a new license to run CoverityAnalysis 6.5 unless you want to use the three new features of 6.5.
FLEXnet licenses provide floating-node features, including the counting of license usage against a centrallymaintained limit. See Section 2.3.1.2.3, “Installing Coverity Analysis components” [p. 35] for details.
30
2.3.1.1. Coverity Platform License Options
Coverity Connect and Coverity Platform licensing has not changed for version 6.6. You can tell whetherthe two products are licensed by looking at the Help menu, in the About option in Coverity Connect.
You can verify what type of license by clicking the About link in Coverity Connect and examining theLicense Packaging field. To request information about the restrictions of your license, or to inquire aboutupgrading your license, contact Coverity Inside Sales at [email protected].
2.3.1.2. Coverity Licensing Feature Support
Coverity Analysis licenses have options that enable or disable functionality in Coverity Analysis and itsinfrastructure. Any combination of the following options can be enabled:
• Quality analysis (C/C++,Java and C#).
• Java Web application security analysis.
• Test analysis.
• Coverity Third Party Integration Toolkit usage.
These options are provided through both of the Coverity Analysis licensing mechanisms: Coverity Analysislicenses and FLEXnet licenses.
For more information about the licenses packages available refer to the license overview.
FLEXnet licenses provide floating-node features, including the counting of license usage against a centrallymaintained limit. See Section 2.3.1.2.3, “Installing Coverity Analysis components” [p. 35] for details.
2.3.1.2.1. Set up Coverity Analysis licensing
You can set up licensing after installing Coverity Analysis. This procedure is necessary if you did not doso already through the Coverity Analysis installer, if you need to replace a trial license with a productionlicense, or if you need to update your license. Coverity Analysis has two licensing mechanisms: Defaultlicensing and FLEXnet licensing.
Note
Coverity Analysis is supported on virtual machines (VMs) only if you use FlexNet licensing ora default license that is not node-locked to a particular host machine.
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 analyzeyour code.
On some Windows platforms, you might need to use administrative privileges when youcopy the Coverity Analysis license to <install_dir>/bin. Due to file virtualization
31
Installing Coverity Analysis
in some 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-clickmenu of the executable for the command interpreter (for example, Cmd.exe or Cygwin) orWindows Explorer.
To set up FLEXnet licensing:
1. Verify that your platform is supported (see Part 4, “Supported Platforms” [p. 80]).
2. Read Section 2.3.1.2.2, “Flexnet” [p. 32].
2.3.1.2.2. Flexnet
This chapter contains information about FLEXnet licensing, which is an alternative to the default licensingprocess, which is described in Section 2.3.1.2.1, “Set up Coverity Analysis licensing ” [p. 31].
Installing FLEXnet licenses
Coverity Analysis supports FLEXnet licensing for C/C++, Java, and C# analyses.
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. Thisinformation is helpful for troubleshooting purposes.
Table 2.3.1. Coverity commands mapped to FLEXnet licensing features
FLEXnet licensing featureCoverity command
analysis.master and analysis.workercov-analyze
analysis.master and analysis.workercov-analyze-cs
analysis.master and analysis.workercov-analyze-java
analysis.infrastructurecov-commit-defects
analysis.infrastructurecov-format-errors
analysis.master and analysis.workercov-make-library
analysis.infrastructurecov-configure
There is one analysis.master for each analysis job.
There is one or more analysis.worker; one for each analysis worker. The number of parallel analysisworkers for cov-analyze and cov-analyze-java is specified in the -j <number-of-workers>option. There is exactly one worker each for cov-analyze-cs and cov-make-library.
To set up FLEXnet licensing for Coverity Analysis:
32
Installing Coverity Analysis
1. Run the generate-flexnet-hostid command and send the results [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 willbe used for FLEXnet licensing.
2. 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 duringthe analysis and committing of defects.
3. Start the license server manager from the <install_dir_sa>/bin directory by running thefollowing command:
> [nohup] lmgrd -c coverity.lic
Note
The lmtools command is required to run lmgrd as a service on Windows systems.Coverity Analysis supports lmtools as documented in the FLEXnet License AdministrationGuide, but does not ship with it. To download and install lmtools, go to:
http://www.globes.com/support/fnp_utilities_download.htm
The version of lmgrd must be 11.5 or higher on all but the following platform, whichrequires version 11.4.1 or higher:
• HP-UX 11.11 for the PA-RISC processor
The FLEXnet License Administration Guide is located at<install_dir>/doc/en/publisher-licensing-toolkit-v11.5/LicenseAdministration.pdf.
The lmgrd command runs in the background. To run lmgrd in the foreground or to debug FLEXnetlicense server problems on Windows, use the -z option. Avoid the -z option on UNIX or Linuxsystems 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 possibleto 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.
4. Edit the <install_dir_sa>/bin/license.config file to add your license serverconfiguration information using the following syntax:
license-server [<port1>]@<server1>[,[<port2>]@<server2> ... ]
33
Installing Coverity Analysis
Important
The server name that is set by the LM_LICENSE_FILE environment variable is used if itis valid, and supersedes the license-server setting in the license.config file.
Important
The license.config file that is used for FlexNet licensing needs to end with a newlinecharacter - that is - end with a blank line. If it does not, cov-analyze will not recognizethe 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 LicenseAdministration Guide, FLEXnet Publishing Licensing Toolkit 11.5.
2.3.1.2.3. Installing Coverity Analysis components
To install Coverity Analysis:
1. Verify that your operating system and compiler versions are supported.
See Part 4, “Supported Platforms” [p. 80].
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-6.6.0.sh.
For Windows systems, double-click the .exe program, for example:
> sh cov-analysis-win64-6.6.0.exe
Depending on whether you are using Linux or Windows, the installer uses a text-based console modeor a graphical mode. The installation choices for graphical and console modes are identical.
For guidance with changing the installer mode, see Chapter 2.1, Coverity installer modes [p. 16].
4. Accept the license agreement.
5. Choose the Coverity Analysis tools that you want to install.
Select from the following check-boxes:
1. Static and Coverity Dynamic Analysis
2. Extend SDK
34
Installing Coverity Analysis
3. Architecture Analysis
Some Coverity Analysis tools have dependencies on other tools if in order to install and use them, souse the following guidelines to choose the correct options:
• To install the Coverity Analysis and Coverity Dynamic Analysis analysis engines (if CoverityDynamic Analysis is available on your platform) select check-box 1. Coverity Dynamic Analysisrequires Coverity Analysis to be installed.
• To install one instance of Coverity Extend SDK, select check-box 1 and check-box 2.
• To install Architecture Analysis only, select check-box 3.
• To install one of the analysis engines and Architecture Analysis, select check-box 1 and check-box3.
6. Choose your license file type:
1. Coverity - Choose this option if you are using a licence file with a .dat extension, for examplelicense.dat. To obtain or inquire about your license file from Coverity, send mail [email protected].
2. FLEXnet - Choose this option if you are using a FLEXnet licence file.
3. Both - Choose this option if you have FLEXnet licensing for Coverity Analysis and want to useCoverity Dynamic Analysis (Coverity Dynamic Analysis only uses Coverity licensing).
Note
The Coverity Analysis installation process will not continue if you do not specify a validlicense file or license server location.
7. 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 thelocation of your license (.dat).
8. For FLEXnet licensing: Setup your FLEXnet license.config file.
If you chose the FLEXnet or Both option for the license type, this step sets up the configuration filethat tells cov-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 thelicense 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 promptsyou 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 6.6Administration Guide (located in the <install_dir_ca>/doc directory).
3. Use an existing license.config file - Choose this option if you have an existing FLEXnetconfiguration file. This option prompts you to specify the location of the configuration file.
35
Installing Coverity Analysis
9. Choose a destination directory for the Coverity Analysis tools.
In this document, the Coverity Analysis installation directory is referred to as <install_dir_ca>.
10. On Windows, choose whether you want to create Start Menu folders and shortcuts.
11. After the installation finishes, add <install_dir_ca>/bin to your PATH environment variable.
2.3.1.3. Uninstalling 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-supplieddata, manually delete the installation directory after running the uninstall or uninstall.exescript.
2.3.1.4. Coverity Analysis platform availability and directory structure
The following table lists the Coverity Analysis products that are available to each supported platform.
Table 2.3.2. Coverity Analysis product platform availability
ArchitectureAnalysis
SDK andSDKCompiler
CoverityDynamicAnalysisa
C#Analysis
JavaAnalysis
C/C++Analysis
Platform
✓AIX
✓✓freebsd
✓✓HP-UX
✓✓✓✓✓Linux 32 or 64-bit
✓✓Linux -ai64
✓✓✓✓Mac OS X
✓✓NetBSD
✓✓✓✓Solaris-sparc
✓✓✓✓Solaris-x86
✓✓✓✓✓✓Windows 32 or 64-bitacov-manage-im and cov-copy-overrun-triage are available on the same platforms as Coverity Dynamic Analysis
After installation, the Coverity Analysis analysis projects and documentation are located in the followingdirectories:
• Coverity Analysis
Coverity Analysis tools and binaries are located at the top level installation directory. For example, theCoverity Analysis commands are located in:
<install_dir_ca>/bin
36
Installing Coverity Analysis
All of the Coverity Analysis product documentation is accessible from the following locations:
1. <install_dir_ca>/doc/en/index.html (English)
2. <install_dir_ca>/doc/ja/index.html (Japanese)
• Coverity Dynamic Analysis
If your platform and license supports Coverity Dynamic Analysis, the tools and binaries are located inthe following directory:
<install_dir_ca>/dynamic-analysis
• Architecture Analysis
The Architecture Analysis tools and binaries are located in the following directory:
<install_dir_ca>/architecture-analysis
Architecture Analysis requires you to point to a valid license in order to install the application. To accessthe Architecture Analysis documentation, install the Architecture Analysis application and see the onlinehelp.
• cov-manage-im and cov-copy-overrun-triage
<install_dir_ca>/bin
• Coverity Wizard
<install_dir_ca>/bin
Coverity Wizard starts automatically after installation of Coverity Coverity Analysis. For information,see Using Coverity Wizard to get started with Coverity Analysis.
37
Installing Coverity Analysis
Chapter 2.4. Installing Coverity Desktop
This chapter describes installation procedures for Coverity Desktop for Eclipse and Coverity Desktop forMicrosoft Visual Studio.
2.4.1. Installing Coverity Desktop for Eclipse, Wind River WorkBench,and QNX Momentics
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 package 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. Ifyou have difficulty signing in and cannot access the Downloads page, it might be because you do not havethe appropriate role permissions or user credentials. If this occurs, contact your system administrator.
Installation requirements:
• Eclipse 3.5 - 3.8 or 4.2 (for Eclipse users).• Wind River WorkBench 3.3.1, 3.3, or 3.2 (for Wind River WorkBench users).• QNX Momentics 4.7, 4.8, or 5.0 (for QNX users).• Java Runtime Environment 5 or later• Eclipse C/C++ Development Tooling (CDT), only for the C/C++ analysis• Eclipse Java Development Tools (JDT), only for the Java analysis
2.4.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 CoverityDesktop when the update site is updated with the new version.
1. Under the Coverity Connect Help menu, select Downloads. Then, copy the URL associated with yourIDE, or click the copy link icon.
For Eclipse:
http://<host>:<port>/coverity-desktop-eclipse/update
For Eclipse (over SSL):
https://<host>:<port>/coverity-desktop-eclipse/update
For WorkBench:
http://<host>:<port>/coverity-desktop-workbench/update
For WorkBench (over SSL):
https://<host>:<port>/coverity-desktop-workbench/update
For QNX Momentics:
38
http://<host>:<port>/coverity-desktop-qnx/update
For QNX Momentics (over SSL):
https://<host>:<port>/coverity-desktop-qnx/update
Note
The default HTTPS port is 8443
2. In the IDE, go to Help → Install New Software...
Note
For Wind River WorkBench only, you must go to the Device Debug perspective to makesure 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 installthe Coverity plug-in.
3. Click the Add... button.
4. In the Location field, enter the update site URL and click OK.
5. Select Coverity Desktop C/C++ Analysis, Java Analysis (for Eclipse only), and/or Coverity TestAdvisor Policy Editor (Test Advisor users only).
Coverity Desktop Java Analysis allows you to view and triage Java static defects.
Coverity Desktop C/C++ Analysis allows you to view and triage C/C++ static defects.
Coverity Test Advisor Policy Editor allows you to create and edit Test Advisor policy files.
6. For Coverity Test Advisor Policy Editor, click the "Available Software Sites" link to add the XTextsoftware site. XText contains several dependencies for the policy editor and needs to be listed amongyour IDE's software sites. If it's not already listed, complete the following steps:
1. Click the Add button.
2. Give the site a name for your reference, "XText" for example.
3. Enter the url for the XText download site in the Location field. The correct address ishttp://download.eclipse.org/modeling/tmf/xtext/updates/composite/releases/
4. Click OK to add the site.
5. Click OK to return to the installation window.
7. Click Next.
8. Click Next and review the Coverity Product License Agreement.
9. Select the I accept the terms of the license agreement radio button.
10. Click Finish.
During installation on Eclipse 3.5 only, a selection dialog will prompt the following:
39
Installing Coverity Desktop
Do you trust these certificates?
Select the certificate(s) and click OK. This allows the installation process to complete.
Note
The installation process might take a long time to complete because Eclipse checks forupdates for all of the selected update sites installed on your environment. To speed up theinstallation, you can go to Help → Software Updates → Available Software → ManageSites. Uncheck all of the update sites except for cov-desktop-eclipse-6.6.0. Whenyou 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.
For information about configuring Coverity Desktop, see the Coverity Desktop online help. To accessthe help, select Help → Coverity Help Center, then open Coverity Desktop 6.6 for Eclipse, Wind RiverWorkBench, and QNX Momentics: Usage Guide and Checker Reference.
2.4.1.2. Installing Coverity Desktop from your local desktop
1. Download and extract cov-desktop-eclipse-6.6.zip for Eclipse,cov-desktop-windriver-6.6.zip for WorkBench, or cov-desktop-qnx-6.6.zipfor QNX Momentics.
2. Select Help → Install New Software.
Note
For Wind River WorkBench, you must go to the Device Debug perspective to make surethat the Install New Software... is present in the Help menu.
Additionally, do not use the Help → Install into Eclipse... option. This option does not installthe Coverity plug-in.
3. Click the Add... button.
4. Click Local and browse to the <CD_package_dir>/cov-desktop-eclipse-6.6, the<CD_package_dir>/cov-desktop-windriver-6.6, or the<CD_package_dir>/cov-desktop-qnx-6.6 directory.
5. Click OK for the Browse For Folder dialog.
6. Click OK for the Add Site dialog. In Eclipse 3.6, click OK for the Add Repository dialog.
7. Select Coverity DesktopC/C++ Analysis, Java Analysis (Eclipse only), and/or Coverity Test AdvisorPolicy Editor (Test Advisor users only).
Coverity Desktop Java Analysis allows you to view and triage Java static defects.
Coverity Desktop C/C++ Analysis allows you to view and triage C/C++ static defects.
Coverity Test Advisor Policy Editor allows you to create and edit Test Advisor policy files.
40
Installing Coverity Desktop
8. For Coverity Test Advisor Policy Editor, click the "Available Software Sites" link to add the XTextsoftware site. XText contains several dependencies for the policy editor and needs to be listed amongyour IDE's software sites. If it's not already listed, complete the following steps:
1. Click the Add button.
2. Give the site a name for your reference, "XText" for example.
3. Enter the url for the XText download site in the Location field. The correct address ishttp://download.eclipse.org/modeling/tmf/xtext/updates/composite/releases/
4. Click OK to add the site.
5. Click OK to return to the installation window.
9. Click Next.
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.
During installation on Eclipse 3.5 only, a selection dialog will prompt the following:
Do you trust these certificates?
Select the certificate(s) and click OK. This allows the installation process to complete.
Note
The installation process might take a long time to complete because Eclipse checks forupdates for all of the selected update sites installed on your environment. To speed up theinstallation, you can go to Help → Software Updates → Available Software → ManageSites. Uncheck all of the update sites except for cov-desktop-eclipse-6.6.0. Whenyou 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 theCoverity Desktop 6.6 for Eclipse, Wind River WorkBench, and QNX Momentics: Usage Guide andChecker Reference. To access the help, select Help → Help Topics. In the Contents pane, selectCoverity Desktop for use with Eclipse.
2.4.1.3. Uninstalling Coverity Desktop
This section describes the steps to remove Coverity Desktop from Eclipse and WorkBench.
In Eclipse, Desktop C/C++ Analysis and Desktop Java Analysis are displayed as separate components inthe installed components window. If you want to re-install or upgrade one of them, you must uninstallthem both.
41
Installing Coverity Desktop
To remove Coverity Desktop:
1. In Eclipse, go to Help → About Eclipse SDK
In WorkBench, go to Help → About Wind River WorkBench
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), and Coverity Test AdvisorPolicy Editor.
4. Click Uninstall.
5. Restart the IDE.
2.4.2. Installing Coverity Desktop for Microsoft Visual Studio
The Coverity Desktop product 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 usethe update URL through the Visual Studio Gallery feature.
To access the download page, sign in to Coverity Connect and click Downloads from the help menu. Ifyou have difficulty signing in and cannot access the Downloads page, it might be because you do not havethe appropriate role permissions or user credentials. If this occurs, contact your system administrator.
Prerequisites:
• Visual Studio 2012, Visual Studio 2010, Visual Studio 2008, or Visual Studio 2005 (except ExpressEditions)
• You must have an instance of Coverity Connect to connect to in order to configure Coverity Desktopto run analyses and commit results.
• For any Windows and Visual Studio version, both .NET 3.5 sp1 and .NET 4.0 are required to install theCoverity Desktop plug-in. Windows Vista and Windows 7 also require update KB959209.
• Administrative privileges (for example, the Administrator user or a user in the Administrators or PowerUsers groups)
2.4.2.1. Installing Coverity Desktop from your local desktop
1. From the Coverity Connect Downloads page, download Coverity Desktop .zip file.
2. Extract the Coverity Desktop zipped file.
3. Close all instances of Visual Studio.
4. Run the setup file, CoverityDesktop.msi.
5. Follow the installer instructions.
6. Start Visual Studio and open a solution that you want to analyze or triage.
7. Go to Coverity → Options to configure Coverity Desktop.
42
Installing Coverity Desktop
2.4.2.2. Installing and updating Coverity Desktop for Visual Studio 2012 using aGallery
You can set up a private gallery in Visual Studio 2012 to install Coverity Desktop or automatically updatethe Coverity Desktop plug-in from within Visual Studio when a new version is available.
To use this feature, you must configure a private gallery in Visual Studio and use the gallery URL providedin Coverity Connect as the gallery site. Visual Studio will then use the URL to install or to automaticallycheck the Coverity Connect server for updated versions of Coverity Desktop. To get the URL from CoverityConnect, go to Downloads page and copy the gallery URL or click on the link icon to copy it.
You can also install the Visual Studio 2012 plug-in from your local desktop by downloading theCoverity.Desktop.Vs2012.vsix file.
For information about creating and managing a private gallery in Visual Studio 2012, seehttp://msdn.microsoft.com/en-us/library/hh266746.aspx.
For more information about setting up a private gallery using registry settings, seehttp://msdn.microsoft.com/en-us/library/hh266735.aspx.
2.4.3. Installing Coverity Analysis for local analysis
If the Coverity Connect system administrator has configured the Downloads page to include the CoverityAnalysis installer, you can download it (and optionally the license.dat license file) to your systemto. 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 alicense.config file in <SA_install_dir>/bin.
4. When you configure Coverity Desktop for local analysis, you can point the configuration to yourlocal Coverity Analysis instance.
43
Installing Coverity Desktop
Chapter 2.5.Troubleshooting for FLEXnet licensing
You might encounter the following common issues with licensing of Coverity Analysis for C/C++, Java,or C#. For more information about the license server manager and FLEXnet licensing, see the LicenseAdministration 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.5.1. A long message displays when I run the lmgrd command.
Solution The following FLEXnet marketing message displays when you run the lmgrdcommand. Realerror messages often proceed or follow it. Make sure to scroll up to the top of your screen toread any error messages that display. For the sake of brevity, this content is removed from theremaining 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 license13:53:54 (lmgrd) usage data into an organized repository,13:53:54 (lmgrd) please enable report logging. Use Macrovision's13:53:54 (lmgrd) software license administration solution,13:53:54 (lmgrd) FLEXnet Manager, to readily gain visibility13:53:54 (lmgrd) into license usage data and to create13:53:54 (lmgrd) insightful reports on critical information like13:53:54 (lmgrd) license availability and usage. FLEXnet Manager13:53:54 (lmgrd) can be fully automated to run these reports on13:53:54 (lmgrd) schedule and can be used to track license13:53:54 (lmgrd) servers and usage across a heterogeneous13:53:54 (lmgrd) network of servers including Windows NT, Linux13:53:54 (lmgrd) and UNIX. Contact Macrovision at13:53:54 (lmgrd) www.macrovision.com for more details on how to13:53:54 (lmgrd) obtain an evaluation copy of FLEXnet Manager13:53:54 (lmgrd) for your enterprise.13:53:54 (lmgrd) 13:53:54 (lmgrd) -----------------------------------------------
2.5.2. 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.lic13:53:54 (lmgrd) -----------------------------------------------...13:53:54 (lmgrd) -----------------------------------------------13:53:54 (lmgrd) FLEXnet Licensing (v11.5.0.0 build 56285 amd64_re3) started on
44
bl-1-4 (linux) (4/3/2008)13:53:54 (lmgrd) Copyright (c) 1988-2007 Macrovision Europe Ltd. and/orMacrovision 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.com13:53:54 (lmgrd) License file(s): coverity.lic13:53:54 (lmgrd) lmgrd tcp-port 2700013: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_re313:53:54 (covlicd) Server started on bl-1-4 for: prevent.platform
13:53:54 (covlicd) prevent.dotnet prevent.java prevent.ccpp13:53:54 (covlicd) EXTERNAL FILTERS are OFF13:53:54 (lmgrd) covlicd using TCP-port 60185
2.5.3. The license server cannot verify my license.
Solution The license.config file might be incorrectly configured or empty. Verify that the licenseserver in the <install_dir_sa>/bin/license.config file correctly points to wherethe lmgrd command is running.
The DNS server might be down. If the DNS server is down, use an IP address in thelicense.config file instead of a hostname.
The license server might not be running. If it is not running, use the lmgrd command to startit.
The firewall on the license server might be blocking the lmgrd port. If so, make sure that theserver where the lmgrd command is running does not block ports 27000 through 27009 forincoming TCP messages.
2.5.4. The license manager cannot initialize.
Solution If you use the lmgrd command without the -c option, the command fails and displays an errormessage that includes the text Cannot find license file at the top of the output onthe 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.datLicense 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) -----------------------------------------------...14:04:49 (lmgrd) -----------------------------------------------14:04:49 (lmgrd) Using license file "/usr/local/flexlm/licenses/license.dat"
45
Troubleshooting for FLEXnet licensing
2.5.5. 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 causesconfusion. 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 onrh el3x86 (linux) (5/11/2007)21:04:27 (lmgrd) Copyright (c) 1988-2007 Macrovision Europe Ltd. and/orMacrovis ion Corporation. All Rights Reserved.21:04:27 (lmgrd) US Patents 5,390,297 and 5,671,412.21:04:27 (lmgrd) World Wide Web: http://www.macrovision.com21:04:27 (lmgrd) License file(s): coverity.lic21:04:27 (lmgrd) lmgrd tcp-port 2700021:04:27 (lmgrd) Starting vendor daemons ...21:04:27 (lmgrd) Started covlicd (internet tcp_port 35916 pid 5362)21:04:27 (covlicd) FLEXnet Licensing version v11.5.0.0 build 56285 i86_re321:04:27 (covlicd) Feature prevent.platform is not enabled yet, starts on12-may -200821:04:27 (covlicd) Feature prevent.ccpp is not enabled yet, starts on12-may-200 821:04:27 (covlicd) License server system started on rhel3x8621:04:27 (covlicd) No features to serve, exiting21:04:27 (covlicd) EXITING DUE TO SIGNAL 36 Exit reason 421:04:27 (lmgrd) covlicd exited with status 36 (No features to serve)21:04:27 (lmgrd) covlicd daemon found no features. Please correct21: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 using21: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.lic21: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 resolvethis, replace all the 0xA0 characters in the license file with spaces. In this case, the follow messagedisplays:
$ ./lmgrd -c coverity.lic 9:58:10 (lmgrd)9:58:10 (lmgrd) -----------------------------------------------...9:58:10 (lmgrd) -----------------------------------------------9:58:10 (lmgrd) 9:58:10 (lmgrd) 9:58:10 (lmgrd) FLEXnet Licensing (v11.5.0.0 build 56285 amd64_re3) started onbl-1-4 (linux) (4/23/2008)9:58:10 (lmgrd) Copyright (c) 1988-2007 Macrovision Europe Ltd. and/orMacrovision Corporation. All Rights Reserved.9:58:10 (lmgrd) US Patents 5,390,297 and 5,671,412.
46
Troubleshooting for FLEXnet licensing
9:58:10 (lmgrd) World Wide Web: http://www.macrovision.com9:58:10 (lmgrd) License file(s): coverity.lic9:58:10 (lmgrd) lmgrd tcp-port 270009:58:10 (lmgrd) Starting vendor daemons ... 9:58:10 (lmgrd) Started covlicd (internet tcp_port 50476 pid 9281)9:58:10 (covlicd) FLEXnet Licensing version v11.5.0.0 build 56285 amd64_re39:58:10 (covlicd) License server system started on bl-1-49:58:10 (covlicd) No features to serve, exiting9:58:10 (covlicd) EXITING DUE TO SIGNAL 36 Exit reason 49:58:10 (lmgrd) covlicd exited with status 36 (No features to serve)9:58:10 (lmgrd) covlicd daemon found no features. Please correct9: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 using9: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.5.6. The lmutil lmdown command cannot shut down the license server.
Solution The license server is not running. The following message displays:
$ lmutil lmdownlmutil - Copyright (c) 1989-2007 Macrovision Europe Ltd. and/or MacrovisionCorporation. All Rights Reserved.Shutdown failed: Cannot connect to license server system. (-15,570:115"Operation now in progress")
2.5.7. 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 lmutillmdiag command works as expected.
$ lmutil lmdiag"commit" v2008.03, vendor: covlicdLicense server: localhostfloating license starts: 1-jan-1990, expires: 26-mar-2008
This license can be checked out
2.5.8. The clock difference is too large between the client and server systems.
Solution If the time difference between the client and server systems is larger than two days, thecov-analyze, cov-analyze-cs, cov-analyze-java, cov-commit-defects,and cov-format-errors commands will not run because they cannot verify the license.
2.5.9. 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"
47
Troubleshooting for FLEXnet licensing
2.5.10. 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.5.11. 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 thelicense 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 problem23:41:25 (lmgrd) and is not recommended.23:41:25 (lmgrd) Can't make directory /usr/tmp/.flexlm, errno: 2(No such fileor directory)23:41:25 (lmgrd) Can't make directory /usr/tmp/.flexlm, errno: 2(No such fileor directory)23:41:25 (lmgrd) Can't open /usr/tmp/.flexlm/lmgrdl.29777, errno: 2license 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 Nosuch file or directory
2.5.12. 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 thelicense server. To terminate the license server, manually terminate all lmgrd and covlicdprocesses.
2.5.13. The covlicd command exits unexpectedly.
Solution If the lmgrd and covlicd commands run on an unsupported platform, the following errormessage displays:
./lmgrd -c coverity.lic18: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 onlee-linux (linux) (4/26/2008)18:20:04 (lmgrd) Copyright (c) 1988-2007 Macrovision Europe Ltd. and/ orMacrovision Corporation. All Rights Reserved.18:20:04 (lmgrd) US Patents 5,390,297 and 5,671,412.
48
Troubleshooting for FLEXnet licensing
18:20:04 (lmgrd) World Wide Web: http://www.macrovision.com18:20:04 (lmgrd) License file(s): coverity.lic18:20:04 (lmgrd) lmgrd tcp-port 2700018:20:04 (lmgrd) Starting vendor daemons ...18:20:04 (covlicd) FLEXnet Licensing version v11.5.0.0 build 56285i86_re318:20:04 (covlicd) lmgrd version 11.4, covlicd version 11.518:20:04 (lmgrd) Started covlicd (internet tcp_port 35481 pid 22149)coverity@lee-linux:~/prevent-linux-4.0.0.beta1/bin$ 18:20:04(covlicd) Server started on lee-linux for: prevent.platform18:20:04 (covlicd) prevent.ccpp18:20:04 (covlicd) EXTERNAL FILTERS are OFF18:20:04 (lmgrd) covlicd using TCP-port 3548118:20:04 (lmgrd) covlicd exited with status 0 signal = 1718:20:04 (lmgrd) Since this is an unknown status, license server18:20:04 (lmgrd) manager (lmgrd) will attempt to re-start the vendor daemon.18:20:04 (covlicd) FLEXnet Licensing version v11.5.0.0 build 56285i86_re318:20:04 (covlicd) lmgrd version 11.4, covlicd version 11.518:20:04 (lmgrd) REStarted covlicd (internet tcp_port 43652 pid 22155)18:20:04 (covlicd) Server started on lee-linux for: prevent.platform18:20:04 (covlicd) prevent.ccpp18:20:04 (covlicd) EXTERNAL FILTERS are OFF18:20:04 (lmgrd) covlicd using TCP-port 4365218:20:04 (lmgrd) covlicd exited with status 0 signal = 1718:20:04 (lmgrd) Since this is an unknown status, license server18:20:04 (lmgrd) manager (lmgrd) will attempt to re-start the vendor daemon.18:20:04 (covlicd) FLEXnet Licensing version v11.5.0.0 build 56285i86_re318:20:04 (covlicd) lmgrd version 11.4, covlicd version 11.518:20:04 (lmgrd) REStarted covlicd (internet tcp_port 55809 pid 22161)18:20:04 (covlicd) Server started on lee-linux for: prevent.platform18:20:04 (covlicd) prevent.ccpp18:20:04 (covlicd) EXTERNAL FILTERS are OFF18:20:04 (lmgrd) covlicd using TCP-port 5580918:20:04 (lmgrd) covlicd exited with status 0 signal = 1718:20:04 (lmgrd) Since this is an unknown status, license server18:20:04 (lmgrd) manager (lmgrd) will attempt to re-start the vendor daemon.18:20:04 (covlicd) FLEXnet Licensing version v11.5.0.0 build 56285i86_re318:20:04 (covlicd) lmgrd version 11.4, covlicd version 11.518:20:04 (covlicd) Cannot open lock file. errno=11 (/var/tmp/lockcovlicd): Resource temporarily unavailable18:20:04 (covlicd) EXITING DUE TO SIGNAL 41 Exit reason 918:20:04 (lmgrd) REStarted covlicd (internet tcp_port 56164 pid 22167)18:20:04 (lmgrd) covlicd exited with status 41 (Exited because another serverwas running)18:20:04 (lmgrd) MULTIPLE "covlicd" license server systems running.18:20:04 (lmgrd) Please kill, and run lmreread18: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).
49
Troubleshooting for FLEXnet licensing
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 supportedby Coverity.
2.5.14. The lmutil lmhostid --help command does not display the -ether option.
Solution The lmutil lmhostid -ether command generates the MAC addresses of all NICs thatare used for FLEXnet licensing.
For more information about the lmutil lmhostid -ether option, see the lmhostidsyntax in the License Administration Guide, FLEXnet Publishing Licensing Toolkit 11.5. TheEthernet address term in the FLEXnet documentation is incorrect. An accurate term is MACaddress.
2.5.15. 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. Themessage 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.5.16. License failure for systems configured to use IPv6.
Solution Systems configured to use IPv6, which is now standard for some Linux distributions, can haveproblems using FlexNet licensing with either Coverity Analysis for C/C++ or Coverity Analysisfor Java. If the server pointed to in the license.config file is @localhost you might getone 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-java --max-mem 1024 --dir data junit-4.1.jar --findsource src
Coverity Static Analyzer for JavaVersion 5.0.0 (pj5.0dev-push-2255)using Java 1.6.0_07 (Sun Microsystems Inc.)
License check failed.
50
Troubleshooting for FLEXnet licensing
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 withlmutil lmdiag -c <license>. If it is running, try changing the license.configfile to use @127.0.0.1 instead of @localhost. Next, rerun cov-analyze orcov-analyze-java.
2.5.17. 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 newlinecharacter - that is - end with a blank line. If it does not, cov-analyze will not recognize thelast line of the file. Leave a blank line at the end of the license.config file.
2.5.18. On Linux environments, the FLEXnet licensing does not work with Ethernet devices that havethe LAN port mapped to anything other than eth0.
Solution The FLEXnet licensing manager (FLEXlm), expects to get the MAC address only from the eth0device. If the licensing machine LAN port is mapped to eth1 or higher, it will not get the correctMAC address. The solution is to map the LAN to eth0.
51
Troubleshooting for FLEXnet licensing
Part 3. Coverity Connect system tuning, maintenance,and monitoring
This part provides important information about tuning your system and database to ensure that your system is achievinga high level of performance. In addition, this part provides guidelines for maintaining the size of the Coverity Connectdatabase, as well as tools that you can use to diagnose problems in case the performance of your system seemssub-optimal.
Chapter 3.1. Post-installation - what's next?
This section provides a list of tasks for you to preform to bring your entire deployment into production.This section does not provide the "how to" information for each task, but references the documentationthat contains the information.
3.1.1. cov-analysis configuration and set-up
The tasks mentioned below are described in full in the Coverity® Analysis 6.6 Administration Guide.
Run the Coverity® SAVE Static Analysis Verification Engine getting started tutorialThe Getting Started documentation allows you to run a basic analysis on provided sample code forC/C++, Java, and C#. After the analysis, you can commit the results to Coverity Connect to make surethat the system is configured properly before running analysis on your code base.
Coverity also provides the Coverity Wizard which allows you to configure compliers, configure andperform a build, configure and perform an analysis, and commit the results to Coverity Connect througha GUI wizard.
Generate a compiler configurationBefore running your first C/C++ or Java analysis, you typically generate a configuration of your nativecompiler.
Enable analysis checkersCoverity® SAVE Static Analysis Verification Engine runs checkers that detect specific types of issuesin your source code. For example, the RESOURCE_LEAK checker finds many types of resource leaksfrom variables that go out of scope while "owning" a resource, such as freshly allocated memory.Checkers are classified by language (C/C++, C#, and Java) and grouped by the types of problems thatthey detect.
Create custom models to improve analysis resultsA custom model is a piece of source code that is written by a developer to replace the actualimplementation of a function or method. Custom models can lead to a more accurate analysis byhelping Coverity® SAVE Static Analysis Verification Engine find more issues and eliminate falsepositive results.
3.1.2. cov-platform system configuration and set-up
The tasks mentioned below are described in full in the Coverity® Platform 6.6 Usage and AdministrationGuide.
Configuring sign-in optionsControls user access to Coverity Connect.
Setting up SSLConfigure Coverity Connect to encrypt communications using SSL.
Connecting to an LDAP databaseThe LDAP configuration feature for Coverity Connect allows site administrators to enter thisinformation only once, and all LDAP-compliant applications can use this central resource.
Configuring email notificationYou can enable Coverity Connect to send email to notify developers of new issues or issues thatchanged triage states.
53
Creating and/or importing usersCreate or import users into your system. You can also create and organize users in groups.
Setting up role-based access controlRole-based access control (RBAC) is a feature that restricts system access to authorized CoverityConnect users.
Creating streams and projectsYou create a stream to support issue data on a portion of your code base. Each stream is organizedinto a project, which can support multiple streams.
Creating data storesA 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 ofCIDs) found in the streams.
Configuring componentsThe components feature allows you to logically group source code files in named entities. Definingcomponents allows you to filter issues and files to show the relationship between source code anddevelopment teams, assign issues to only the users or groups that are responsible for a particular sectionof the code, and limit access to code and issues
Tune your system for optimum performanceSee Chapter 3.2, Coverity Connect system and database tuning [p. 55].
Establish a database back-up scheduleSee Section 3.4.2, “Backing up the database” [p. 65].
Create a database maintenance scheduleSee Chapter 3.4, Maintaining and backing up the Coverity Connect database [p. 64].
Create a system monitoring scheduleSee Chapter 3.3, Monitoring and diagnosing Coverity Connect performance [p. 60].
3.1.3.The Coverity Deployment Maturity Model
The deployment maturity model provided by Coverity consulting services is a program that takes yourdeployment's level of maturity into consideration and works with you to craft a roadmap towards successfuladoption and integration of development testing into your development life cycle. Beginning with acomprehensive understanding of your business goals, use cases and technical environment, CoverityProfessional Services will create a deployment plan based on a level-by-level assessment that aligns withyour organizational objectives.
For more information, see http://www.coverity.com/services/professional-services.html.
54
Post-installation - what's next?
Chapter 3.2. Coverity Connect system and database tuning
This chapter provides a series of recommendations that you can implement in your Coverity Connectdeployment to help the system run more efficiently and more reliably. This section includes the following:
• PostgreSQL tuning parameters
• System tuning options (memory allocation settings)
• JVM tuning options (Java heap settings)
In addition, this section provides information about how to use some diagnostic scripts that will aid youin the tuning process.
Tuning Coverity Connect and its related components is an iterative process that can vary for differentdeployments. Each deployment is unique and might require further customization to suit specificrequirements. It is recommended to keep detailed records of your tuning and configuration settings in caseyou need to revert your changes.
Note
Note that after you make any tuning changes, you will need to restart the Coverity Connectapplication and database. For more information, see Section 2.2.7, “Stopping and starting CoverityConnect” [p. 29].
3.2.1. PostgreSQL database tuning - embedded database
When you run the version 6.6 Coverity Connect installer, you select a database performance level for aLarge, Medium, or Demo system. These option apply to the PostgreSQL database that is embedded withCoverity Connect.
• The Medium (and default) configuration settings are:
shared_buffers = 2GB#shared_buffers = 512MB # Windows max. valuework_mem = 64MBmaintenance_work_mem = 256MBwal_buffers = 16MBcheckpoint_segments = 128effective_cache_size = 4GBtrack_counts = on
• The Large settings are:
shared_buffers = 1/4 the total available RAMmaintenance_work_mem = 1/8 the total available RAMwork_mem = shared_buffers/32effective_cache_size = 1/2 available RAM (whichever is higher).
• The configuration settings for a Demo setting are the PostgreSQL database defaults. No tuning settingsare re-written.
To change your PostgreSQL database configuration, you can edit the postgresql.conf. This file isin the following location, if you chose the default location during the installation or upgrade:
55
• <install_dir_cc>/database/ (Unix systems)
• <install_dir_cc>\database\ (Windows systems)
Table 3.2.1. postgres.conf settings
Setting and notesParameter
Set this to 25% of available RAM.
For Windows only: Due to the way PostgreSQL is implemented in Windows,the maximum value for shared_buffers is 1024MB. On Windows, PostgreSQL
shared_buffers
relies heavily on OS caching. This limits the ability to tune memory on thisplatform and impacts performance negatively. Windows should only be usedfor trial purposes only, not for production environments.
This amount is allocated per session for operations such as sorts (CoverityConnect usually spawns ~30) threshold for disk-based sorts. If it calls for morespace, the sort will happen on disk (which is much slower).
work_mem
Depends on storage device/system. (16MB assuming that you are restoring ontoan OWC drive. Allocates approximately 4000 I/Ops per process. Otherwise, it
effective_io_concurrency
should be equal to the number of drives in your RAID array or 1 for a singledrive).
16MB (for the write-ahead-log. Only requires enough space for logging, notqueries).
wal_buffers
128 (more segments means less log writing contention) .checkpoint_segments
50% (embedded DB) of available RAM (the threshold amount the postgreSQLuses to determine if queries can be managed in memory. Does not count towardactual mem usage) 75% (dedicated DB) of available RAM
effective_cache_size
You must stop and restart Coverity Connect after you change these parameters. Use cov-im-ctl stopto stop Coverity Connect and cov-im-ctl start to restart it.
For more information about these settings (or for information about tuning your external database), seethe PostgreSQL documentation at http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server.
Note
On Linux systems, the database might fail to start after you restart Coverity Connect because thePostgreSQL request for shared memory exceeded your kernel's SHMMAX parameter. If this occurs,you will receive an error message similar to the following:
FATAL: could not create shared memory segment: Invalid argumentDETAIL: Failed system call was shmget(key=5432001, size=2209701888, 03600).
For detailed information about shared memory configuration, see the Managing Kernel Resources sectionof the PostgreSQL documentation at http://www.postgresql.org/docs/current/static/kernel-resources.html.
If you have a machine with a large amount of RAM, you may want to increase the allocation to PostgreSQL.This allocation must account for memory already reserved by the JVM. To prevent over-committing,subtract the JVM allocation from the total available RAM on the system when calculating these values.The following suggestions assume 64GB of available RAM with 32Gb(50%) allocated to the JVM. Theassumed DB size is ~150Gb using an solid state drive (SSD) for both the application and database.
56
Coverity Connect system and database tuning
3.2.2.Tuning shared memory settings
3.2.2.1. Shared memory settings for Linux systems
The amount of available RAM determines the recommended values for kernel parameters used byPostgreSQL processes. Assuming 64GB of RAM, the following kernel parameters should be set in the/etc/sysctl.conf file:
To check your SHMMAX setting, run the following command:
> sysctl -a | grep -i shm
The command will display your SHMMAX (and SHMALL) setting. For example:
kernel.shmmax = 33554432kernel.shmall = 2097152
To increase SHMMAX (for example, to 1GB), add the following parameter to the /etc/sysctl.conffile:
kernel.shmmax = 1073741824
After you add the parameter, run the following command:
> sysctl -p
Or, you can use the following script to determine shmmax and shmall on systems that support getconf.In order to use this script, you must either be root, copy what the script outputs into /etc/sysctl.conf,or run sysctl -p.
#!/bin/bash# simple shmsetup scriptpage_size=`getconf PAGE_SIZE`phys_pages=`getconf _PHYS_PAGES`shmall=`expr $phys_pages / 2`shmmax=`expr $shmall \* $page_size` echo kernel.shmmax = $shmmaxecho kernel.shmall = $shmall
The above script provides only an estimation. PostgreSQL calculates shared memory using both theshared_buffers parameter and the total number of connections calculated using max_connections. In these cases, the actual kernel parameters for shmmax and shmall will vary (usually being higherthan the calculated value of this script). If PostgreSQL fails to start, consult the required values based onthe guidance provided in the $CIM_HOME/database/pgctl.log or reduce the number ofmax_connections (default is 100).
Table 3.2.2. Linux shared memory settings
Setting and notesParameter
The maximum size of a shared memory segment value based on amount of availablesystem RAM. Default should be 1/2 Total RAM on a dedicated system. 1/4 on an
kernel.shmmax
embedded. calculated based on the system page size (4096 is the default) andkernel.shmall.
The total size of Shared Memory Segments in pages.kernel.shmall
57
Coverity Connect system and database tuning
The shmmax parameter should greater than or equal to the amount specified for the shared_bufferssetting in the postgresql.conf file. In the table above, shmmax is set to 32GB or 50% of the totalavailable RAM.
3.2.2.2. Project shared memory settings for Solaris 10
Both PostgreSQL and the JVM require the shared memory to be set appropriately. For an embeddeddatabase, the user/group used in the commands should belong to the user responsible for installing CoverityConnect. In the case of an external database, the settings will need to be set on both the database andapplication servers.
Solaris defaults to a SHMMAX setting of one-fourth (1/4) of the system RAM. If you need to increase thisin order to set shared memory settings higher, you should use a project setting associated with thePostgreSQL user. For example, run the following as root:
# projadd -c "PostgreSQL DB User" -K "project.max-shm-memory=(privileged,8GB,deny)" / -U postgres -G postgres user.postgres
Additionally, if you are running PostgreSQL inside a zone, you might need to raise the zone resource usagelimits as well. For more information, see the official Oracle Solaris documentation about projects andprctl at http://docs.oracle.com/cd/E19455-01/817-1592/rmtaskproj-1/index.html.
Note
You must reboot the machine if you make any changes to the shared memory. Otherwise, theapplication might fail to start with the following error:
Could not reserve enough space for object heap
3.2.3. JVM settings
This section includes tuning recommendation for the Java Virtual Machine. JVM parameters for CoverityConnect must be placed in the <install_dir_cc>/config/system.properties files in thejava_post_opts 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 performancetuning options you chose:
For Medium (default) installation tunings:
-Xms=3840m-Xmx=3840m
For Large installation tunings:
-Xms=Maximum memory / 2-Xmx=Maximum memory / 2
58
Coverity Connect system and database tuning
3.2.3.1. Required JVM settings
Table 3.2.3. Issue markers
Setting and notesParameter
Explicitly set the server runtime (as opposed to the client runtime). There areno additional arguments.
-server
Set the minimum heap size. Ideally, set the minimum and maximum heap sizevalues to the same amount to prevent expensive garbage collection whichhappens when the heap is resized. Usage:
-Xms8g
-Xms
Set the maximum heap size. Usage:
-Xms8g
-Xmx
Set the maximum permanent generation size. Usage:
-XX:MaxPermSize=256m
-XX:MaxPermSize=
3.2.3.2. Optional JVM settings
The following parameters are optional, but are recommended for optimization:
Table 3.2.4. Optional JVM settings
Settings and notesParameter
Enable (+) the use of 32-bit ordinary object pointers in 64-bit JREs canprovide faster and more efficient 32-bit addressing for OOPs at theexpense of heap size. Note that will limit heap to a maximum of 32Gb.
-xx:+UseCompressedOops
Disable (-) the garbage collection overhead limit. When this parameteris disabled, OutOfMemoryExceptions are suppressed when more
-XX:UseGCOVerheadLimit
than 98% of the total time is spent in garbage collection and less than2% of the heap is recovered. Note that this might allow the applicationto hang when the heap is under-provisioned.
59
Coverity Connect system and database tuning
Chapter 3.3. Monitoring and diagnosing Coverity Connectperformance
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 you organization sothat you can continually record performance numbers. This way, you can have a trend of system performanceover time to asses the health of the system.
Additionally, this section provides tools that will help you diagnose issues if you suspect that there is adegradation in performance.
3.3.1. Linux monitoring and diagnosis tools
You can use the following commands to monitor and diagnose the performance of your Coverity Connectdeployment on Linux:
CPU Core CountThe following command will help you monitor the CPU usage. Note that this does not counthyperthreading (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 RAMThe following command will help you monitor the total RAM usage:
# cat /proc/meminfo | grep MemTotal
Shared MemoryThe following commands allow you to view the RAM that is shared between applications on yoursystem.
# sysctl -a | grep kernel.shmmax# sysctl -a | grep kernel.shmall
3.3.1.1. Diagnosing performance problems
You can use the he Linux/Unix top 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
Table 3.3.1. top command options
DescriptionOption
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 IObottleneck exists. This command might display misleading values and should be used with other fields to support/deny a particular diagnosis path.
iowait
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 withhigh SWAP values need to be tuned in order to decrease the swap space.
SWAP
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 RAMto be at least 15% of the database size.
Mem
For usage information, see the http://linux.die.net/man/1/top.
60
3.3.1.2. Diagnosing I/O problems
If an IO bottleneck is presumed to exist in the system, iostat can assist in finding it. The following tablelists the recommended options that you can use to diagnose performance problems with iostat. Runiostat with -x to see all fields.
Table 3.3.2. top command options
DescriptionOption
Displays the number of milliseconds spent servicing requests high values indicatethat the device might be overloaded. Spikes in svctm and await are usually normal
svctm and await
and only drives that show persistently slow service times should raise alarm. Youcan try running iostat -d 1 -x > iostatout.txt to look at persistentdata. This will measure IO every second for as long as it is left to run.
A value of 100% means the device is saturated with requests.%util
Indicates the average queue size. High values along with high svctm, await anda %util near 100% likely means the device is overloaded with read/write requests.
avgqu-sz
For usage information, see http://linux.die.net/man/1/iostat.
3.3.2. Windows monitoring and diagnosis tools
You can use the following commands to monitor and diagnose the performance of your Coverity Connectdeployment on Windows:
CPU Core CountThe following command will help you monitor the CPU usage.
# systeminfo | findStr "Processors(s)"
Total RAMThe following command will help you monitor the total RAM usage:
# systeminfo | findStr "Total Physical Memory"
3.3.2.1. Using the Performance Monitor to diagnose Coverity Connect issues
The Performance Monitor for Windows shows persistent values for various system statistics includingCPU, RAM and IO Counters. The following example shows an overview of how to use the PerformanceMonitor on Windows 7. Note that this is must an example. For usage information, see the PerformanceMonitor 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 thelogs.
61
Monitoring and diagnosing Coverity Connect performance
6. Click Data Collector Sets → User Defined → <name of the set you just created> in theConsole Tree.
7. Click the Play button on the top toolbar.
8. Attempt the task which is under-performing/failing to complete (commit, upgrade, viewing issues,triaging, and so forth).
9. Press the Stop button.
10. You can now view the data by clicking the view latest report button (a small green log book icon) onthe top toolbar.
Use the following descriptions to diagnose the performance issue:
Table 3.3.3. Defect event processing
DescriptionOption
CPU Counters
Measures the time the processor spends receiving and servicing hardwareinterruptions during specific sample intervals. This counter indicates a possiblehardware issue if the value is greater than 15%.
Processor \ % InterruptTime
This indicates the number of threads in the processor queue. The server doesn'thave enough processor power if the value is more than two times the numberof CPUs for an extended period of time.
System \ Processor QueueLength
IO Counters
Measures the percentage of free space on the selected logical disk drive. Takenote if this falls below 15%, as you risk running out of free space for the OSto store critical files. One solution is to add more disk space.
LogicalDisk \ % Free Space
Indicates how many I/O operations are waiting for the hard drive to becomeavailable. If the value is larger than the two times the number of spindles,
PhysicalDisk \ Avg. DiskQueue Length
that means the disk itself may be the bottleneck. This is of particular interestwhen considering a RAID array as one disk may become overloaded as aresult of the configuration.
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
PhysicalDisk \ % Idle Time
system is saturated. They may consider replacing the current disk systemwith a faster disk system. Not that alone, this is not a very strong indicatorfor an existing problem.
Measures the average time, in seconds, to read data from the disk. If thenumber is larger than 10 milliseconds (ms), that means the disk system is
PhysicalDisk \ Avg. DiskSec/Read
experiencing latency when reading from the disk. The most logical solutionhere is to replace the current disk system with a faster disk system if possible.
Measures the average time, in seconds, it takes to write data to the disk. Ifthe number is larger than 10 ms, the disk system is experiencing latency when
PhysicalDisk \ Avg. DiskSec/Write
writing to the disk. The most logical solution here is to replace the currentdisk system with a faster disk system if possible.
Memory Counters
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/very small
Memory \ % CommittedBytes in Use
62
Monitoring and diagnosing Coverity Connect performance
DescriptionOption
This indicates insufficient memory if the number is greater than 80%. Likelyan indication of thrashing. Look to the Pool Paged Bytes and Avaliable Mbytes(see below).
Measures the amount of physical memory, in megabytes, available for runningprocesses. If this value is less than 5 percent of the total physical RAM, that
Memory \ Available Mbytes
means there is insufficient memory, and that can increase paging activity. Toresolve this problem, you should add more memory.
Measures the amount of physical memory, in megabytes, available for runningprocesses. If this value is less than 5% of the total physical RAM, that means
Memory \ Pool Paged Bytes
there is insufficient memory, and that can increase paging activity. To resolvethis problem, you should add more memory.
Measures the rate at which pages are read from or written to disk to resolvehard page faults. If the value is greater than 1,000, as a result of excessivepaging, tuning the JVM and Postgresql settings is likely required.
Memory \ Pages per Second
Network Counters
Measures the rate at which bytes are sent and received over each networkadapter, including framing characters. The network is saturated if you discover
Network Interface \ BytesTotal/Sec
that more than 70 percent of the interface is consumed. For example, for a100-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).
Measures the length of the output packet queue, in packets. There is networksaturation if the value is more than 2 for an extended period of time.
Network Interface \ OutputQueue Length
3.3.3. Solaris monitoring tools
You can use the following commands to monitor the performance of your Coverity Connect deploymenton Solaris:
CPU core countTo determine the CPU core count, use the following command:
# psrinfo -pv
Shared MemoryTo determine the shared memory, run a similar command to the following. Note that this commandRequires an existing project for the <project_name>. If there is no existing project, you candetermine the defaults by using $$ for the <project_name>.
# prctl [project_name] | awk '/project.max-shm-memory/ {getline; print $0}'
Total RAMUse the following command to determine the total RAM used by you system:
# prtconf | grep "Memory size"
63
Monitoring and diagnosing Coverity Connect performance
Chapter 3.4. Maintaining and backing up the Coverity Connectdatabase
After you have deployed the Coverity products and have brought you system into production,
3.4.1. Maintaining the size of your database
With each commit to Coverity Connect or any additions to the number of Coverity Connect entities (users,groups, components), the size of your database will grow. The rate that the database grows is based onmany factors including the number of defects and snapshots (which will vary for every organization) andthe number of lines of code in a given project. Because of this, predicting the size of database over timeis extremely difficult, however is it important to both monitor and maintain the size of your database overtime.
The database password is located in the <install_dir_cc>/config/cim.properties file.
3.4.1.1. Database settings
These settings are recommended for maintaining the size of your embedded or external database:
Table 3.4.1. Database performance tuning settings - embedded
Settings and notesParameter
Requires maintenance mode. For example:
$CIM_HOME/postgres/bin/reindexdb --all --echo -h localhost -U coverity
REINDEX
Table 3.4.2. Database performance tuning settings - external
Settings and notesParameter
Do not output commands to set ownership of objects to match the originaldatabase. By default, pg_restore issues ALTER OWNER or SET SESSION
--no-owner
AUTHORIZATION statements to set ownership of created schemaelements. These statements will fail unless the initial connection to thedatabase is made by a superuser (or the same user that owns all of theobjects in the script). With -O, any user name can be used for the initialconnection, and this user will own all the created objects.
Prevent restoration of access privileges (grant/revoke commands).--no-acl
Execute the restore as a single transaction (that is, wrap the emittedcommands in BEGIN/COMMIT). This ensures that either all the commands
--single-transaction
complete successfully, or no changes are applied. This option implies--exit-on-error.
OPTIONAL: Exit if an error is encountered while sending SQL commandsto the database. The default is to continue and to display a count of errorsat the end of the restoration.
--exit-on-error
3.4.1.2. Purge snapshot details
The Purge Snapshot Details feature allows you to schedule a clean-up process in which Coverity Connectautomatically removes snapshot information that you might no longer need if more current snapshot
64
information is available. This feature is recommended because it allows you to reduce and maintain thesize of the Coverity Connect database. This feature is also recommended instead of deleting snapshots, ifyou have been using snapshot deletion in previous versions to save database size. Snapshot purging isfaster, more efficient, and preserves your snapshot and triage history.
This feature is implemented as follows:
1. During the installation of Coverity Platform - This installation option sets a preconfigured interval forthis feature. For more information, see Chapter 2.2, Installing Coverity Platform [p. 20].
2. Through the Coverity Connect administration configuration menu - This allows you to customize yourinterval settings. These configuration setting override the installation settings if you chose to implementthem. For more information, see the Coverity® Platform 6.6 Usage and Administration Guide.
It is highly recommended to back up and restore your database after the purge process completes.
3.4.2. Backing up the database
As with any system that contains important data, it is highly recommended to develop a process for regularbacking-up the PostgreSQL database. It is up to you to decide the back-up schedule (and this might dependon how large the database is and how long the back-up takes), but it is a good idea to always have a relativityrecent back-up. For example, if anything were to go wrong with your system at some point, you will havea successful back up that you can restore into production. It is also important to make a back-up of yourdatabase when you make changes to the system, such as new feature implementation, major systemconfiguration changes, major tuning changes, upgrades, and so forth.
This section provides information about backing up and restoring the data in Coverity Connect either foran embedded or external PostgreSQL database.
There are two utilities for backing up your Coverity Connect installed in an embedded PostgreSQL database.
• Using the cov-admin-db command line utility (embedded only).
The you can manually run (or create a script to automatically run) cov-admin-db backup tobackup your database, and cov-admin-db restore to restore it. For more information, see thecov-admin-db description in the Coverity® 6.6 Command and Ant Task Reference.
• Backing up or scheduling a backup through the Coverity Connect UI (embedded only).
The backup utility in the Coverity Connect Configuration menu allows you to make or schedule a back-upof the current state of your database. For more information, see the Coverity® Platform 6.6 Usage andAdministration Guide.
3.4.3. System performance reference
The following numbers demonstrate a typical system with very good performance. These numbers are notmeant for you measure against your system, because any number of variable can add or subject from yourbuild, commit, or analysis times. This is simply provided as reference.
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
65
Maintaining and backing up the Coverity Connect database
• OWC Mercury EXTREME Pro 6G SSD (SATA III mode)
For system configuration settings, the system uses the recommended JVM and PostgreSQL shipped as thedefault settings. The memory is optimized for 8GB of total RAM.
3.4.3.1. Build
13:13:15 cov-emit phase: 1047 seconds.
3.4.3.2. Analysis
13:32:28 Analysis summary report:13:32:28 ------------------------13:32:28 Files analyzed : 442513:32:28 Total LoC input to cov-analyze : 285821613:32:28 Functions analyzed : 8496313:32:28 Paths analyzed : 617450913:32:28 Time taken by analysis : 00:19:1313:32:28 Defect occurrences found : 4539 Total13:32:28 1 ALLOC_FREE_MISMATCH13:32:28 50 ARRAY_VS_SINGLETON13:32:28 1 ASSERT_SIDE_EFFECT13:32:28 154 ATOMICITY13:32:28 3 BAD_COMPARE13:32:28 9 BAD_FREE13:32:28 2 BAD_SIZEOF13:32:28 21 BUFFER_SIZE13:32:28 48 BUFFER_SIZE_WARNING13:32:28 251 CHECKED_RETURN13:32:28 100 CONSTANT_EXPRESSION_RESULT13:32:28 16 COPY_PASTE_ERROR13:32:28 280 DEADCODE13:32:28 30 DIVIDE_BY_ZERO13:32:28 51 EVALUATION_ORDER13:32:28 426 FORWARD_NULL13:32:28 15 INCOMPATIBLE_CAST13:32:28 6 INFINITE_LOOP13:32:28 73 INTEGER_OVERFLOW13:32:28 151 LOCK13:32:28 255 MISSING_BREAK13:32:28 242 MISSING_LOCK13:32:28 9 MIXED_ENUMS13:32:28 25 NEGATIVE_RETURNS13:32:28 20 NESTING_INDENT_MISMATCH13:32:28 406 NO_EFFECT13:32:28 103 NULL_RETURNS13:32:28 23 ORDER_REVERSAL13:32:28 28 OVERFLOW_BEFORE_WIDEN13:32:28 317 OVERRUN13:32:28 2 PASS_BY_VALUE13:32:28 10 PW.ASSIGN_WHERE_COMPARE_MEANT13:32:28 1 PW.BOOLEAN_CONTROLLING_EXPR_IS_CONSTANT13:32:28 6 PW.BRANCH_PAST_INITIALIZATION13:32:28 12 PW.CONVERSION_TO_POINTER_ADDS_BITS13:32:28 8 PW.INCLUDE_RECURSION13:32:28 2 PW.MISSING_INITIALIZER_ON_CONST13:32:28 52 PW.PARAMETER_HIDDEN13:32:28 5 PW.PARAM_SET_BUT_NOT_USED
66
Maintaining and backing up the Coverity Connect database
13:32:28 54 PW.POINTER_CONVERSION_LOSES_BITS13:32:28 14 PW.PRINTF_ARG_MISMATCH13:32:28 17 PW.SIGNED_ONE_BIT_FIELD13:32:28 2 PW.SWITCH_SELECTOR_EXPR_IS_CONSTANT13:32:28 2 PW.USELESS_TYPE_QUALIFIERS13:32:28 135 RESOURCE_LEAK13:32:28 2 RETURN_LOCAL13:32:28 168 REVERSE_INULL13:32:28 13 REVERSE_NEGATIVE13:32:28 61 SIGN_EXTENSION13:32:28 9 SIZECHECK13:32:28 20 SIZEOF_MISMATCH13:32:28 1 STACK_USE13:32:28 5 STRAY_SEMICOLON13:32:28 8 STRING_NULL13:32:28 1 STRING_SIZE13:32:28 3 SWAPPED_ARGUMENTS13:32:28 355 TAINTED_SCALAR13:32:28 4 TAINTED_STRING13:32:28 7 TOCTOU13:32:28 199 UNINIT13:32:28 32 UNREACHABLE13:32:28 114 UNUSED_VALUE13:32:28 85 USE_AFTER_FREE13:32:28 14 VARARGS13:32:28 13:32:28 cov-analyze: 1153 seconds.
3.4.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...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
67
Maintaining and backing up the Coverity Connect database
Chapter 3.5. Deployment Scenarios
This section describes several full deployment scenarios of software organizations that use Coverityproducts. These scenarios demonstrate how various organizations with different infrastructures deployedCoverity Analysis and Coverity Platform and show the possibilities for improved efficiencies in theorganization.
The use cases depict the following deployment scenarios:
• Section 3.5.1, “Scenario 1: Increasing the number of concurrent commits” [p. 68]
• Section 3.5.2, “Scenario 2: Optimal performance for commits, application performance, and UIresponse” [p. 71]
• Section 3.5.3, “Scenario 3: Increasing performance over time” [p. 76]
These scenarios are directed at build engineers, systems administrators, enterprise architects, and systemsarchitects. The goal of these scenarios is for you to understand how similarly-sized organizations (in relationto your organization) deployed and implemented Coverity products.
Each scenario describes a deployment story including the initial state of the deployed environment, theissues facing the deployment, and the hardware, software, and feature options that were put in place sothat the performance goals were achieved. This way, you can plan for you deployment to run optimallythe upon installation and configuration.
3.5.1. Scenario 1: Increasing the number of concurrent commits
In this use case scenario, a business unit in a telecommunications company uses Coverity products toincrease the quality of their released and internal-use software. As the organization integrated the analysisprocess into their build process, there was a need to configure the system to increase the number ofconcurrent commits, increase performance, and manage the size of the database. The story below describesthe process of how this organization achieved these goals.
3.5.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 Service to improve and stabilize performance
3. Future goal - Expand the use of Coverity Connect from 50% to 70% of users
3.5.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 allocatedfor a number of Coverity Connect instances which are currently experiencing difficulty scaling concurrentcommits. Given the size and number of commits being generated by the build process, the database sizewas also increasing in an unsustainable rate.
• The objective of the integration team was to continue to be able to perform auto-triaging of defects (suchas auto-assignment and notification) using existing or newer versions of the web services API. Thisintegration used a python script invoked by the build process. Given the initial performance difficulties,
68
the organization experienced issues automating snapshot deletion through web services (such as slowor incomplete operations) and was unsure if this was related to performance, changes in the web serviceAPI behavior, or flaws in the integration script.
3.5.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 andJava components.
• Feature branch aggregation - All code branches are essentially different feature branches derived froma common source with target-specific hardware.
• Coverity Analysis runs on build machines which are run as a cluster. The organization uses LFS forscheduling the builds against target platforms which meet run requirements. While builds are scheduledin 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 slightvariations, 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 andstaging machines. All are standalone instances with embedded PostgreSQL databases.
3.5.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 theanalysis.
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 readyto release.
3.5.1.2.2. Preconditions
The following section describes the conditions that must be implemented or accepted in order to completethe optimization of the deployment:
• Sufficient resources for the optimization process (see Section 3.5.1.2.4, “Hardware” [p. 70]). Generally,the RAM should be no less than 15% of the database size. Initially, the organization had an 800GBdatabase. The size of the database was reduced using manual snapshot deletion to approximately 350GB.
69
Deployment Scenarios
• The ability to isolate build behavior from integration behavior. Each could be triggered separately to beable to diagnose them in isolation.
• The ability to make configuration changes to the Coverity Connect configuration files as well as anyunderlying operating system parameters.
• A staging environment to test changes, or the ability to restart production systems during the diagnosisprocedure.
3.5.1.2.3. Diagnostics
This section describes the actions that identity the problem with a particular aspect of the deployment andimplement 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 amountof the 256GB of RAM was allocated to the Coverity Connect PostgreSQL database (128GB). The JVMwas 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 Connectserver due to the limited impact of downtime, but moving forward, a staging instance is going to beused.
• After the above optimizations were in place, the commit concurrency threshold was increased from thedefault of 5 and also specified a commit queue of 100. The organization tried commit concurrencythresholds 8, 16, and finally 24. During testing, the load was monitored on the Coverity Connect serverto ensure that resources were not overcommitted. Given the 24 hour job threshold, the combination ofperformance tuning allowed the organization to easily reach the acceptance criteria of 8 commits over24 hours.
• After performance was optimized, it was determined that the Coverity Connect Web Services APIintegration scripts were failing due to changes in the API. Corrective action required involvement ofprofessional services which required migration to V6 of the Web Services API and changes to the existingscripts.
3.5.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 Mem1600MHz 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
3.5.1.2.5. Custom configuration and tuning settings
The following system parameters were set optimal performance.
In system.properties:
70
Deployment Scenarios
• tomcat_max_heap=auto
• java_opts_post=-server -Xms64g -Xmx64g -XX:MaxPermSize=4g
In postgresql.conf:
• shared_buffers=128GB
• work_mem=4GB
• maintenance_work_mem=4GB
• effective_io_concurrency = 4
• wal_buffers=32MB
• checkpoint_segments=128
• effective_cache_size=128GB
3.5.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 whichthe organization was unaware of the implications of this decision. This is less than ideal as triageinformation 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 managedatabase 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 usinga the purge snapshot details feature and a subsequent back-up and restore operation.
3.5.2. Scenario 2: Optimal performance for commits, applicationperformance, and UI response
In this use case scenario, a software organization of a computer storage company uses Coverity to measurequality. After initial deployment, there was a need to configure the system to increase the number ofconcurrent commits, to increase performance, and to increase the performance and responsiveness of theCoverity Connect user interface. The story below describes the process of how this organization achievedthese goals.
3.5.2.1. Goals
The overall goals optimize 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 login as it used as a measure of theapplication's responsiveness.
71
Deployment Scenarios
4. Secondary goal - Validation of Coverity-recommended best practices.
5. Future goal - Improvement of the upgrade process.
3.5.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 byvarious ASIC families and the product branches based on these families. The objective of this groupwas to scale commits (and the database) to be able to keep up with the approximately 1000 streamsbeing managed by Coverity Connect.
• The initial environment consisted of a VMWare ESXi virtualized application server (with 2 CPUs and8GB of reserved RAM) against a standalone database. The ESXi host was provisioned with 2x Intelx5550 (for a total of 8 cores) and 144GB of RAM connected to 8Gb FC Storage. All guest VMDK filesare on VMFS3 formatted data stores.
The Coverity Connect VM ran alongside 15 other VMs with fewer resources assigned. This configurationdid perform given the targeted deployment scope. Dedicated enterprise hardware was deployed for boththe application and database layers (which are separate) to address performance issues but challengesstill remained with regards to configuring the application environment to take advantage of these additionalresources.
• Given the number of full commits being generated by both automated builds and developers, databasesize was increasing at an unmanageable rate which forced the organization to use the snapshot deletionprocess to manage database growth. As well as impacting performance, delete operations also preventedthem from instituting an audit policy for their clean-before-checkin process.
• Due to the high criticality of Coverity integration to their development process, measures where takento ensure high-availability.
3.5.2.2. Deployment story
The organization's basic deployment infrastructure is as follows:
• Primary load - Full (not partial) local developer desktop commits and baseline commits used for defectcomparison (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 threegeographically distributed and one local design center. All commits happen locally to the centralizedCoverity Connect instance.
• A dedicated build machine is used to create baseline commits of their projects, which are used forcomparison against local developer commits. This comparison is accomplished by using a WebServices-based script that emulates the preview report functionality in older version of Coverity Connect(in which this feature did not exist).
72
Deployment Scenarios
• Clean before check-in process
1. The central build machine processes important branches with Coverity targets to serve as the baselinefor comparison.
2. Desktop integration via Perforce performs a pre- check-in operation which involves commit localresults to the central CIM/CC instance and comparing the baseline to the desktop commit.
3. New and removed defects are reported back to the developer.
3.5.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 commit localresults to the central Coverity Connect instance and comparing the baseline to the Coverity Desktopcommit.
2. New and removed issues are reported back to the developer.
3.5.2.2.2. Preconditions
The following section describes the conditions that must be implemented or accepted in order to completethe optimization of the deployment:
• 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 proveduseful in diagnosing the impact of snapshot deletion on application performance (Section 3.5.2.2.4,“Diagnostics” [p. 73]). In addition, configuration changes could be applied to the Developmentenvironment without impacting Production.
• Provisioning of enterprise hardware and a migration away from virtualized solutions.
3.5.2.2.3. Desired outcomes
• The ability to handle a high number of concurrent commits (50, with a queue of 80) given the numberof 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
3.5.2.2.4. Diagnostics
This section describes the actions that identity the problem with a particular aspect of the deployment andimplement configuration or feature changes to improve or solve the problem.
• Optimization of the JVM - Migration of Coverity Connect to the enterprise hardware initially failedexpectations with regards to the desired commit concurrency threshold. This was due to misconfigurationof the java_post_opts in the cim.properties file. Due to the instability observed in the initialtesting, commits were performed using the rcp1 protocol. The initial target was for 16 concurrentcommits given dedicated application server with 32Gb of RAM. After apply the JVM settings, this wasachieved and further configuration changes were applied to the commitPoolThreads parameter toa maximum of 50 (still using the less efficient rcp1). The organization then performed their tests usingrcp2 with the expectation that there would be modest performance improvements in commit as well.
73
Deployment Scenarios
• The processing load on the centralized Coverity Connect server was 400-450 commits/day 4 days aweek. There was a less significant load on the central Coverity Connect instance the other 3 days of theweek. 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 morethan 70+ seconds in the production environment. This varied significantly from the developmentenvironment (8-9 seconds). It was determined that the significant number of snapshot deletions wasresponsible as these operations significantly impacted the statistics of critical application tables. As aresult, disk-based sorts were being performed in the production database which, in turn, affected loginperformance. Initially, a REINDEX was used to fix the table statistics, but continued production levelusage degraded this response check back to sub-optimal responsiveness. The solution was to removethe LOC license check from the login page with a hotfix which reduced the optimal 8-9 second logintime down to 0.3 seconds.
• Once the database statistics on heavily modified tables was determined to be the root cause of performancedegradation, periodic CLUSTER operations where performed on the top 20 tables with significantstatistics drift (actual tuples versus what was reported in the stats). The CLUSTER operation rebuildsan existing table in index order (in this case, using 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 CLUSTERis that it requires an exclusive table lock. This means that there is the possibility of data contentionbetween the database and the application when this operation is executing. In addition, rebuilding certaintables (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 wasoriginally deployed, migration to 6.5.x was performed. Unoptimized, the upgrade completed inapproximately 46 hours. Configuration of the events environment variables brought this down toapproximately 9 hours.
3.5.2.2.5. Hardware
The environment consists of 3 separate systems - Production, Standby, and Development. Each systemconsists of both an application server and a standalone PostgreSQL database. High-availability in the formof Warm StandyBy [http://www.postgresql.org/docs/8.4/static/warm-standby.html] using WAL shipping.The Development environment is used solely for testing CIM/CC release testing to ensure that unstablebuilds are not pushed out to production.
The database and application server hardware only differ in the amount of RAM available (32Gb for theapplication server and 64GB for the database server) and cores (12 for the application server and 16 forthe 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:
74
Deployment Scenarios
3.5.2.2.6. Custom Coverity Connect configuration and tuning settings
The following system parameters were set optimal performance.
In system.properties:
• java_opts_post=-server -Xms618g -Xmx24g -XX:MaxPermSize=6g
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 whichtarget SSDs (as they are using RAID with standard HDs). No WAL isolation at the file system level.
cov-admin-db.vmpoptions in sysctl.conf:
• -Xmx48g
• -Xms48g
• -XX:MaxPermSize=1g
• -XX:+UseConcMarkSweepGC
• -XX:+PrintGCDetails
• -XX:+PrintGCTimeStamps
• -Xloggc:upgrade.log
Upgrade environment variables
• DB_UPGRADE_EVENTS_LATEST_BATCH=64000
• DB_UPGRADE_EVENTS_NON_LATEST_BATCH=2000000
3.5.2.2.7. Notes
• 1 hr SLA (Service Level Agreement) for high-availability/uptime for Coverity Connect
75
Deployment Scenarios
• The organization has a replicated warm standby system for production. This involves a standby CoverityConnect application server and backing database both of which are for dedicated use. Standbyapplication/database hardware resources are complete duplicates of their production counterparts. WALreplication between the production and standby database is accomplished through an scp script with adrift of approximately 5 minutes.
• A daily 2 hour maintenance window is used to perform CLUSTER operations on the 20 most modifiedtables. The CLUSTER operation rebuilds a table in index order (using the primary key), but requires anexclusive lock which has the potential to interfere with the running application. As they have designcenters located globally, this is a high risk operation, but yields significant performance gains.
3.5.2.2.8. Future considerations
• The use of Purge Snapshot Details in newer Coverity Connect releases. This would allow the organizationto manage database growth through the supported mechanism instead of using the snapshot deletionmechanism (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 amountof commits required as the existing clean before check in validation process only requires a commit ifnew defects are introduced. This would also allow the organization to implement auditing of commitswhich currently is not possible due to the snapshot deletion process to control the database size.
3.5.3. Scenario 3: Increasing performance over time
3.5.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)
3.5.3.1.1. Issues and challenges
• The objective of this group is to improve the usability of the Coverity Connect UI for the purposes oftriaging defects.
• Initially a mixed deployment 4.5 Defect Managers and Coverity Integrity Manager, 5.5.3. Migrationwas performed to unify the projects to the same version of Coverity Connect with subsequent updatesto major releases (6.0.x/6.5.x). The organization encountered upgrade issues in the form of "Out ofMemory" exceptions.
3.5.3.2. Deployment story
• number of Coverity users - 1300 / 500 active (logged 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 Coverity analysis.
• Each Coverity Connect instance is on a dedicated use server
• Coverity Connect is deployed with an embedded PostgreSQL database.
• The deployment is in a non-virtualized environment.
76
Deployment Scenarios
• Limited commit load as analysis submissions are limited to once per day. The average project commitsonce per week. However, given the long history of some projects, database size was beginning to impactUI responsiveness.
3.5.3.2.1. Coverity tools workflow
• Projects are built remotely, and the intermediate directory compressed and submitted for analysis andtriage.
• The submitted project is placed into a processing queue.
• Analysis is performed locally with an email notification regarding new defects being sent when analysishas completed.
3.5.3.2.2. Preconditions
The following section describes the conditions that must be implemented or accepted in order to completethe optimization of the deployment:
• Sufficient resources for the optimization process (see Section 3.5.3.2.5, “Hardwareconfiguration:” [p. 77]).
3.5.3.2.3. Desired outcomes
• Improved user experience of the Coverity Connect UI.
3.5.3.2.4. Diagnostics
This section describes the actions that identity the problem with a particular aspect of the deployment andimplementation configuration or feature changes to improve or solve the problem.
• Login and defect selection were seen when system usage increased. Enabling JMX logging showed thatheap was approaching 12GB of the initial 16Gb of RAM which could force contention with the embeddedPostgreSQL 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 anewer release of Coverity Connect which supported the snapshot purge functionality (Purge SnapshotDetails). Data had accumulated from 2006 to the present; most of that data is no longer relevant. Apolicy was put in place to purge anything older than 365 days. This reduced the database size from110GB reduced to 72GB. The operation took approximate 2.5 days. No space savings was realizedinitially until a backup/restore was performed.
• Coverity Connect clustering was introduced to help scale for demand in terms of new projects (with amajority of the projects have disparate source code bases) with an ideal target of having 150 projectsper machine. The environment was configured with the coordinator and a single subscriber. Both machineswere hosted in the same locale and connected through a local 1GbE network. The initial synchronizationtook 4-5 hours with ongoing synchronization taking between 1-10 minutes (depending on the amountof information to synchronize).
3.5.3.2.5. Hardware configuration:
• Memory: 32GB RAM
• Hard Drives: 2TB SATA (for CC installation) and 4X146GB SAS (for Database - SAS Disk has beensetup as RAID level 10)
77
Deployment Scenarios
• RAID Controller: HP P420i/Software RAID 10 (8 spindles/4 pairs)
3.5.3.2.6. Custom Coverity Connect configuration and tuning settings
The following system parameters were set optimal performance.
In system.properties:
• java_opts_post=-server -Xms618g -Xmx24g -XX:MaxPermSize=6g
In postgresql.conf:
• shared_buffers = 8GB
• work_mem = 256MB
• maintenance_work_mem = 512MB
• wal_buffers = 16MB
• checkpoint_segments = 64
• effective_cache_size = 16GB
cov-admin-db.vmoptions options in sysctl.conf:
• -Xms16g
• -Xmx16g
• -XX:MaxPermSize=368m
• -XX:+UseCompressedOops
• -XX:+UseConcMarkSweepGC
• -XX:+DisableExplicitGC
• -XX:NewSize=2g
• -XX:SurvivorRatio=16
• -Dcom.sun.management.jmxremote
• -Dcom.sun.management.jmxremote.port=8999
• -Dcom.sun.management.jmxremote.ssl=false
• -Dcom.sun.management.jmxremote.authenticate=false
3.5.3.2.7. Notes
• Remote JMX logging imposes a marginal performance penalty. Due to the low load generated in thisuse case, the penalty was acceptable, but it is generally not recommended to always have this enabledunless the organization is troubleshooting application issues or have measured the capacity on a systemand that there are resources to spare.
78
Deployment Scenarios
3.5.3.2.8. Future considerations
• Use of cov-admin-db.vmoptions for upgrades. Given the amount of RAM available on thesystems, the events environment variables could be increased to improve performance of upgrades.
• This use case is not entirely representative of the Coverity Connect Clustering model as both thecoordinator and subscriber are not geographically distributed. In this case, clusterings is used to simplyload balance requests as very few projects require the synchronization of distribute triage stores.
79
Deployment Scenarios
Part 4. Supported PlatformsCoverity provides technical assistance explaining, configuring, debugging, and providing bug fixes and work-aroundsbased on service level agreements on all supported platforms listed in this part. Refer to the maintenance service termsfor more details.
Chapter 4.1. Coverity Connect and Coverity Policy ManagerPlatforms
Coverity Connect and Coverity Policy Manager support the following server platforms and browsers.
Table 4.1.1. Coverity Connect & Coverity Policy Manager server platform support
HardwareArchitecture
32 or 64-bitHost OS versionHost OS
x8664-bitWindows XP/Windows 2003 and higheraWindows
x8664-bitSolaris v10 for x86Solaris
x8664-bitLinux Kernel v2.6 or higher and glibc 2.4 or higherLinuxaCoverity requires a minimum service pack for some Windows versions: SP2 for Windows Server 2008, SP2 for Windows Vista,SP3 for Windows XP, SP2 for Windows 2003.
Coverity Connect supports 8.4 through 9.2 for use with an external database, however, due to an issue withPostgreSQL, it is possible that you can encounter serious performance degradation impacting commitswhen run against PostgreSQL versions 9.1.x and 9.2.x. This issue has no current workaround/tuning tomitigate, so it is recommended to use, or revert to, PostgreSQL version 8.4.17 as an external CoverityConnect database.
Note
Any environment using a 32-bit operating system and/or using the 2GB memory setting shouldonly be used for a non-production Coverity Connect system, such as a product demonstration ora sandbox testing environment.
Table 4.1.2. Coverity Connect & Coverity Policy Manager browser support
VersionBrowser
8 or 9Internet Explorer
Mozilla supported versionsaFirefox
Google supported versionsaGoogle Chrome
5.1.5 or laterSafariaCoverity supports only the Firefox and Chrome versions that are under maintenance, and deprecates all end-of-life versions.
The Coverity Desktop plug-ins for Eclipse, Microsoft Visual Studio, and other supported IDEs require thesame version for the Coverity Analysis and Coverity Platform installations for which Coverity Desktop isconfigured to use. If you use Coverity Desktop, you must upgrade all Coverity products together to thesame version.
If you do not Coverity Desktop, Coverity Connect 6.6 accepts analysis results from any Coverity Analysis(formerly Static Analysis) or Coverity Dynamic Analysis versions equal or previous to the current version.Coverity Connect also accepts analysis results from Prevent versions v4.5.1, v4.5.0, v4.4.1, or v4.4.0.
81
Chapter 4.2. Coverity Analysis and Coverity Dynamic Analysis
4.2.1. Supported platforms
Supported Platforms
Coverity Analysis for C#
Coverity Analysis for C# supports Visual Studio 2005, 2008, 2010, 2012 and their versions ofthe C# compiler (csc.exe).
Coverity Analysis supports the following platforms or virtual machine (VM) implementations of supportedplatforms, except where noted.
Table 4.2.1. Supported platforms: Coverity Analysis and Coverity SDK
FLEXnetLicensing
CoveritySDK
C#Analysis
JavaAnalysisab
C/C++Analysis
Host OS and/or Kernel versionHost OS
✓v5.3 for the PowerPC processorc
AIXv6.1 for the PowerPC processorc
✓
✓
v6.0 (32-bit)d
FreeBSD
v7.1 (32-bit)d
v8.2 (32-bit)d
v8.3 (32 or 64-bit)
v9.1 (32 or 64-bit)
f✓
✓
v11.11 for the PA-RISC 2.0 processor(64-bit)e
HP-UX
✓✓v11.23 for the PA-RISC 2.0 processor(64-bit)g
✓✓✓h✓hKernel v2.6 or higher on (32-bit) x86 or(64-bit) x86_64Linux
✓✓Kernel v2.6 or higher on Itanium/IA64
✓✓hi✓hi
v10.6i
Mac OSX
v10.7 i
v10.8 i
✓
✓
v4 (32-bit)k
NetBSDj v5.x (32 or 64-bit)l
v6.0 (32 or 64-bit)l
✓
✓ m
✓✓
v10 for the (32-bit) x86 and (64-bit)x86_64 processor
Solarisv10 for the (32 or 64-bit) SPARCprocessor
✓✓✓o✓h✓hWindows XP/Windows 2003 and highernWindowsaCoverity supports the execution of Java security analyses (Coverity Security Advisor analyses) and FindBugs analyses (throughCoverity Analysis for Java) on the platforms supported by Oracle Java SE Runtime Environment 7 (JRE-7).
82
bFor information about invoking a particular Java compiler with cov-build, see Table 4.2.2, “Java supported compilers for CoverityAnalysis and Coverity Dynamic Analysis ” [p. 83].cOnly manually integrated build capture is supported because the cov-build command is not available, and it is necessary to runcov-analyze on a fully supported platform. For details, see the references to AIX in the Coverity® Analysis 6.6 AdministrationGuide.dFreeBSD v6.0, v7.1, and v8.2 will no longer be supported in Coverity Analysis versions after 6.6.ePatch PHSS_30966 is required for HP_UX 11.11. A VM implementation on this platform is not supported.fFLEXnet Licensing is not supported on HP_UX 11.11.gPatch PHSS_31807 is required for HP_UX v11.23. A VM implementation on this platform is not supported.hCoverity Wizard is supported on these platforms.iThe following are not supported on the 32-bit x86 platform for v10.6 of Mac OS X: Coverity Wizard (which runs Java and C/C++analyses), FindBugs analyses (through Coverity Analysis for Java), and analyses with Java Web Application Security checkers.jNetBSD 32-bit support covers the x86 processor only, not other 32-bit processors.kNetBSD v4 will no longer be supported in Coverity Analysis versions after 6.6.lBecause of a NetBSD bug, on 64-bit versions of NetBSD, Coverity Analysis will fail while attempting to capture any 32-bit build(or mixed 32 and 64-bit build). To avoid this, you must bypass cov-build and use cov-translate directly.mRequires the libiconv library, and you must configure the system dynamic loader (ld.so.1) to locate it.nCoverity requires a minimum service pack for some Windows versions: SP2 for Windows Server 2008, SP2 for Windows Vista,SP3 for Windows XP, SP2 for Windows 2003.o Coverity Analysis for C# requires .NET 4.0 or .NET 4.5 to run. Coverity Analysis supports analysis of programs produced by theVisual C# compiler (csc.exe) from .NET Framework versions 1.0, 1.1, 2.0, 3.0, 3.5, 4.0, and 4.5.
Note
Coverity Analysis is supported on virtual machines (VMs) only if you use FlexNet licensing ora default license that is not node-locked to a particular host machine.
4.2.2. Supported Compilers: Coverity Analysis for Java and CoverityDynamic Analysis
Compiler support varies based on whether you use the cov-build command. Coverity Analysis for Javaand Coverity 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 6.6 Administration Guide, andsee the cov-build command documentation in the Coverity® 6.6 Command and Ant Task Reference.
• Not using cov-build. For information about this build mode, see the section called "Alternativeanalysis process flow" in the Coverity® Analysis 6.6 Administration Guide, and see the cov-emit-javacommand documentation in the Coverity® 6.6 Command and Ant Task Reference.
Table 4.2.2. Java supported compilers for Coverity Analysis and Coverity DynamicAnalysis
Supported whennot usingcov-build
Supported whenusingcov-build
VersionCompilerHost OS
✓✓v1.6 - v1.7JDK forMac OS X
Mac OS X
✓✓v1.5 - v1.7Sun/OracleJDK
Supportedplatforms otherthan Mac OS X
83
Coverity Analysis and Coverity Dynamic Analysis
Supported whennot usingcov-build
Supported whenusingcov-build
VersionCompilerHost OS
✓Any version that accepts Javasource v1.2 - v1.7 and targetsbytecode v1.2 - v1.7.
Any Javacompiler
All supportedplatforms
4.2.2.1. Coverity Dynamic Analysis for Java
Coverity supports Coverity Dynamic Analysis for Java on the same platforms on which it supports CoverityAnalysis Java . Please refer to Java Static Analysis. Refer to the following list for details:
• Using Coverity Dynamic Analysis for Java requires either running cov-build or using the "Alternativeanalysis process flow" as described in the in the Coverity® Analysis 6.6 Administration Guide, and thecov-emit-java command documentation in the Coverity® 6.6 Command and Ant Task Reference.Please refer to Java Static Analysis for the list of Java supported compilers.
• Coverity supports Coverity Dynamic Analysis for Java on the same platforms that support CoverityAnalysis for Java.
• The Coverity Dynamic Analysis Broker runs on the same platforms that support Java Coverity Analysis.
• On supported Mac OS X platforms, the Coverity Dynamic Analysis Agent runs on the v1.6 or v1.7Apple JVM that ships with the OS. On other supported platforms, the Coverity Dynamic Analysis Agentruns on a v1.5, v1.6, v1.7 Sun/Oracle HotSpot JVM.
4.2.3. Supported Compilers: Coverity Analysis for C/C++
Coverity provides, and supports the Coverity Compiler Integration Toolkit (CIT). This toolkit is used tointegrate compilers with Coverity Analysis for C/C++. Coverity acknowledges that not all compilers canbe integrated using CIT. Coverity provides compiler integrations out of the box for many popular compilers(listed below).
Coverity provides commercially reasonable efforts to support documented compiler features driven bymarket need. Coverity does not generally support undocumented or unintended language features. Toproperly analyze files that use undocumented, unintended, or non-standard features, customers might needto 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 bycase basis but are generally considered "unsupported". Since Coverity will not be able to validate theseissues, we will require very detailed and precise problem reports to begin the investigation.
Coverity provides the following compiler integrations:
Table 4.2.3. Coverity Analysis for C/C++ compiler integrations
TargetHostVersionCompiler
TigerSHARC
Windows
5.0 (7.3.0.5)Analog DevicesVisualDSP++Compilers
SHARC5.0 (8.0.0.8)
Blackfin5.0 (8.0.0.10)
ARMWindowsADS 1.1ARM C and C++
84
Coverity Analysis and Coverity Dynamic Analysis
TargetHostVersionCompiler
Windows/Linux/SolarisADS 1.2
Windows/LinuxRVDS 2.0 - 4.1
DS 5.0
All targetsWindowsCodeGear C++ 5.93
Borland C++a
Borland C++ 5.5.1
Motorola 68HC05
Windows
cx6805 4.2d
Cosmic C CrossCompilers
Motorola 68HC11cx6811 4.1t
Freescale 68HC08 andHCS08
cx6808 4.5.10
Freescale 68HC12 andHCS12
cx6812 4.6i
Freescale HCS12Xcxs12x 4.7.7
Freescale XGATEco-processor
cxxgate 4.2.4
Motorola 68HC16cx6816 4.1r
Freescale MC68332cx332 4.1l
All targetsWindows/Linux4.5Electric CloudElectricAccelerator®b
Wii
Windows
1.0, 1.1, 1.2, 1.3
FreescaleCodewarriorc
StarCore and SDMA1.3
DSi1.3
DS2.0
ARM3.0
E68k3.0.5
StarCore DSP3.1
ColdFire6.4
EPPC 5xx4.1 - 4.3, 8.7
HC124.6
Microcontrollers (HC08)6.1
MPC55xx2.2
DSC56800E8.2
All targets
Windows f
2.7.2 - 4.7.xeGNU GCC and G++d
Linux
Solaris
Mac
FreeBSD
NetBSD
HP-UX
85
Coverity Analysis and Coverity Dynamic Analysis
TargetHostVersionCompiler
PowerPCLinux4.0.7
Green HillsOptimizing C andC++/EC++
PPC MPC83xxPowerQUICC II PRO
Solaris4.2.3
PowerPCWindows
4.0.2 - 2012.1
ARM4.2.3 - 2012.1
Microchip PICCmicrofamilyWindows
9.50PL2 - 9.60PL2HI-TECH PICCCompiler
PIC10/12/16 MCUs9.81
PA-RISCHP-UXA.03.63 - A.03.67HP aCC
ARM
Windows
4.40A - 6.30
IAR EmbeddedWorkbench C/C++
80517.30B - 8.10
MSP4304.10A - 5.30
Atmel AVR4.30 - 6.10
Atmel AVR324.10
Renesas M16C3.21D - 3.50
Renesas R8C3.50
Renesas H82.10B - 2.30
National CR16C3.10
Renesas M32C3.21A - 3.30
Dallas/Maxim MAXQ1.13C - 2.30
Freescale HCS123.20
Samsung SAM83.20
Power, PPCAIX8 - 11IBM XLC
x86Linux9.1 - 12.1Intel C++
XScale MicroarchitectureWindows2.0.1
C51
Windows
8.12
Keil CompilersC1666.11
C2514.53a
ARMRVCT 3.1, 4.0 for uVision
MSAWindows2.0, 3.1Marvell MSA
SymbianWindows3.1Nokia Codewarrior forSymbian
x86
Windows/Linux6.3.2 - 6.5.0QNX C/C++
MIPS
PPC
ARM
Intel XScale
SH-4
86
Coverity Analysis and Coverity Dynamic Analysis
TargetHostVersionCompiler
SuperH
Windows
9.01
Renesas C/C++Compilers
H8S6.02
H86.02
M16C5.41
M32C5.41
M32R5.01
RX1.0
ARM, PPCLinux (32-bit)0.9.8, 1.0.8, 1.0.10, 1.0.11,1.0.12, 1.0.13
Scratchboxg
PS3 PPUWindows
350.1 - 430.1SNC C/C++ Compilerh
PSP20.990 - 1.650
ppu-lv2, spu-lv2Windows360 - 420SNC GNU C/C++Compiler
Renesas SH-4Windows/Linux4.1.1STMicroelectronicsGNU C/C++
ST20Windows2.3.1STMicroelectronicsST Micro C/C++
All targetsSolaris
Studio8: CC and cc 5.5
Sun (Oracle) CC andcc
Studio9: CC and cc 5.6
Studio10: CC and cc 5.7
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
x86Windows/LinuxRA-2006.5Tensilica Xtensaxt-xcc and xt-xtc++compilers
TMS470
Windows
4.1.2 - 4.6.3
Texas InstrumentsCode Composer
TMS320C55x3.2.2 - 4.3.6
TMS320C6x5.1.0 - 7.0.3
TMS320C54x4.1.0 - 4.2.0
TMS320C20004.1.0 - 5.2.6
x86Windows/Linux5.2ER2TriMedia TCScompiler
ARM, MIPS, SH
Windows
Microsoft eMbedded C++4.0ij
Visual Studio x86kMicrosoft Visual C++ 6,2003jl
x86, x86_64, ARM, MIPS,SH
Microsoft Visual C++ 2005,2008, 2010, 2012 jlm n
87
Coverity Analysis and Coverity Dynamic Analysis
TargetHostVersionCompiler
ColdFire
Windows/Linux5.0.x - 5.9.xWind River (formerlyDiab) C/C++
M32R
MC68k
M*CORE
MIPS
PPC
SH
SPARC
ARM[XSCALE]
TriCore
x86
PowerPCWindows4.3g
PPCWindows16.00XBox
All targetsMacgcc 4.2Xcode GCC and G++
ollvm-gcc 4.2
aThe VCL library, which is shipped with Borland compilers, is not supported.bElectricAccelerator support is deprecated in Coverity Analysis 6.6 and will not be supported in future versions.cCodewarrior compilers are supported only for command-line builds. Coverity Analysis does not support the Codewarrior IDE.dVersions of any of these compilers that are modified to accept non-standard syntax are not supported. Not all C++11 features aresupported. C++11 variadic templates are supported.eCoverity Analysis does not support all of the C++11 features that are supported by GCC 4.7.fCygwin 1.7 is supported on all supported platforms. Cygwin 1.5 is supported on Windows XP (32-bit), Windows Server 2003(32-bit), and Windows Vista (32-bit), but is deprecated in Coverity Analysis 6.6. It will not be supported in future releases.
Earlier versions of Cygwin have a bug which can cause cov-build to fail to print the native build's output, and potentially causebuild failures. This can be fixed by upgrading your version of Cygwin. This can be worked around by using --instrument or byredirecting the output of cov-build. This bug is believed to affect Cygwin versions 1.7.1 - 1.7.9.gTo run Coverity Analysis using the Scratchbox compiler, install Coverity Analysis in the/scratchbox/users/$USER/host_usr directory and use the cov-build-sbox and cov-configure-sbox commands.Exit Scratchbox to perform all other operations.hTo obtain additional resources that are necessary for this compiler, contact [email protected] bundles compilers with a number of SDKs, such as the Windows Driver Kit, Window Driver Development Kit, andWindows CE. These compilers are similar to the ones that come with Visual Studio. These compilers are supported as long as theversion number is greater then 12.00, and the target is supported.jThe 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 Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ]
kTargets such as Itanium and x86_64 are not supported.lManaged C++ and Common Language Runtime (CLR) are not supported. Compilations with switches beginning with "/CLR" willbe skipped.mFor Microsoft Visual C++ 2012, not all C++11 features are supported, most notably range-based for loops.nVisual Studio 2012 is the only supported compiler for FxCop and cov-import-msvsca.o In general, Apple language extensions are not supported. Pre-compiled headers, frameworks and header maps are supported.
88
Coverity Analysis and Coverity Dynamic Analysis
Note
The Platform Builder IDE is supported if the compiler that it is using is supported. PlatformBuilder is not a compiler.
89
Coverity Analysis and Coverity Dynamic Analysis
Chapter 4.3. Coverity Test Advisor SCM and platform support
The following tables list the platforms, compilers, and Source Control Management (SCM) systems thatare supported for C/C++ and Java test environments.
The minimum system requirements are the same that are defined for Coverity Analysis. For moreinformation, see the Coverity Analysis.
Browser requirements are the same that are defined for Coverity Connect.
4.3.1. Coverity Test Advisor for C/C++
Table 4.3.1. Test Advisor for C/C++ SCM and platform support
Supportedcompilers
32 or 64-bitHost OSSCM versionSupported SCM Systems
GNU GCC,G++
32 or 64-bit
Linux and Windowsa4.8 and laterAccurev
Linux and Windowsaa7.0.1 - 8.0ClearCase
version
Linux and Windowsaa1.11.17 and laterCVS
3.4.6 orlater
Linux and Windowsaa1.4.4 and laterGit
Linux and Windowsaa1.0 and laterMercurial
Linux and Windowsaa2007.2 and laterPerforce
Linux and Windowsaa1.4.0 and laterSVN
Windowsaa
TFS 2008b
Team Foundation Server
TFS 2010c
TFS 2012d
TFS 2012 Update 1e
TFS 2012 Update 2f
aTest Advisor support for Windows systems requires a licensed installation of the BullseyeCoverage tool. The minimum supportedversion of BullseyeCoverage is 8.7.53. For more information about BullseyeCoverage implementation, see the Coverity® Test Advisor6.6 Usage and Administration Guide.
Additionally, Test Advisor supports Bullseye-supported compilers, but only those compilers that are officially supported by BOTHBullseye and Coverity Analysis. To verify a compiler's support status:
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 Coverity Analysis.
If the compiler appears in both support tables, the compiler is supported. If the compiler ONLY appears in the Bullseye supporttable, then the compiler is not supported by Test Advisor.
bTeam Foundation Server 2008 has the following dependencies:
• Visual Studio 2008 SDK
• Visual Studio Team Explorer 2008
• Team Foundation Server 2008 powertools
cTeam Foundation Server 2010 has the following dependencies:
• Team Foundation Server 2010 powertools
dTeam Foundation Server 2012 has the following dependencies:
90
• Team Foundation Server 2012 powertools
eTeam Foundation Server 2012 update 1 has the following dependencies:
• Team Foundation Server 2012 update 1 powertools
fTeam Foundation Server 2012 update 2 has the following dependencies:
• Team Foundation Server 2012 update 2 powertools
4.3.2. Coverity Test Advisor for Java
Table 4.3.2. Test Advisor for Java SCM and platform support
Supportedcompilers
32 or 64-bitHost OSSCM versionSupported SCM Systems
Sun/OracleJDK, v1.5,
32 or 64-bit
Linux and Windowsa4.8 and laterAccurev
Linux and Windowsaa7.0.1 - 8.0ClearCase
v1.6, andv1.7
Linux and Windowsaa1.11.17 and laterCVS
Linux and Windowsaa1.4.4 and laterGit
Linux and Windowsaa1.0 and laterMercurial
Linux and Windowsaa2007.2 and laterPerforce
Linux and Windowsaa1.4.0 and laterSVN
Windowsaa
TFS 2008b
Team Foundation Server
TFS 2010c
TFS 2012d
TFS 2012 Update 1e
TFS 2012 Update 2f
aTest Advisor support for Windows systems requires a licensed installation of the BullseyeCoverage tool. The minimum supportedversion of BullseyeCoverage is 8.7.53. For more information about BullseyeCoverage implementation, see the Coverity® Test Advisor6.6 Usage and Administration Guide.
Additionally, Test Advisor supports Bullseye-supported compilers, but only those compilers that are officially supported by BOTHBullseye and Coverity Analysis. To verify a compiler's support status:
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 Coverity Analysis.
If the compiler appears in both support tables, the compiler is supported. If the compiler ONLY appears in the Bullseye supporttable, then the compiler is not supported by Test Advisor.
bTeam Foundation Server 2008 has the following dependencies:
• Visual Studio 2008 SDK
• Visual Studio Team Explorer 2008
• Team Foundation Server 2008 powertools
cTeam Foundation Server 2010 has the following dependencies:
• Team Foundation Server 2010 powertools
dTeam Foundation Server 2012 has the following dependencies:
• Team Foundation Server 2012 powertools
eTeam Foundation Server 2012 update 1 has the following dependencies:
91
Coverity Test Advisor SCM and platform support
• Team Foundation Server 2012 update 1 powertools
fTeam Foundation Server 2012 update 2 has the following dependencies:
• Team Foundation Server 2012 update 2 powertools
Note
Test Advisor ships with the Cobertura open source Java test coverage tool.
92
Coverity Test Advisor SCM and platform support
Chapter 4.4. Coverity Security Advisor for Java framework andtechnology support
The Java Web application security checkers support the following frameworks and technologies:
• Java Persistence API (JPA): All versions.
• JavaServer Pages (JSP): Version 2.1 (not 2.2).
• Java Servlet specification: Version 2.5 (not 3.0).
• Spring MVC: Versions 2.x and 3.x.
• Spring core: All versions.
• Hibernate: Versions 3.x and above.
See also, the Java Analysis support notes that pertain to Coverity Security Advisor.
93
Chapter 4.5. Architecture Analysis
Architecture Analysis supports the following platforms:
Table 4.5.1. Architecture Analysis for C/C++ and C# platform support
JRE version32 or 64-bitHost CPUHost OS or kernel versionHost OS
Sun v1.5a, v1.6
32-bitx86Windows Server 2008, Enterprise,SP2
Windows
32-bitx86Windows Server 2008, Enterprise,RTM-SP1
32-bitx86Windows Server 2008, StandardRTM-SP1
32-bitx86Windows Server 2008, StandardSP2
64-bitx86_64Windows Server 2008, Enterprise,R2 (no SP)
64-bitx86_64Windows Server 2008, Enterprise,RTM-SP1
64-bitx86_64Windows Server 2008, Enterprise,SP2
64-bitx86_64Windows Server 2008, Standard,RTM-SP1
64-bitx86_64Windows Server 2008, Standard,SP2
64-bitx86_64Windows Server 2008, Standard,R2 (no SP)
32-bitx86Windows 7, Enterprise (no SP)
64-bitx86_64Windows 7, Enterprise (no SP)
32-bitx86Windows 7, Professional (no SP)
64-bitx86_64Windows 7, Professional (no SP)
32-bitx86Windows 7, Ultimate (no SP)
64-bitx86_64Windows 7, Ultimate (no SP)
32-bitx86Vista, XP, 2003
Sun v1.5, v1.632 or 64-bitx86v2.4, v2.6Linux
Sun v1.5, v1.632 or 64-bitSPARCv8, v9, v10Solaris
x86v10
Sun v1.5, v1.632 or 64-bitx86v10.5 (Universal)Mac OS XaArchitecture Analysis supports JRE version v1.5.0.13 and later.
Table 4.5.2. Architecture Analysis for Java platform support
JRE version32 or 64-bitHost CPUHost OS or kernel versionHost OS
Sun v1.5a, v1.632-bitx86Windows Server 2008, Enterprise,
SP2Windows
94
JRE version32 or 64-bitHost CPUHost OS or kernel versionHost OS
32-bitx86Windows Server 2008, Enterprise,RTM-SP1
32-bitx86Windows Server 2008, StandardRTM-SP1
32-bitx86Windows Server 2008, StandardSP2
64-bitx86_64Windows Server 2008, Enterprise,R2 (no SP)
64-bitx86_64Windows Server 2008, Enterprise,RTM-SP1
64-bitx86_64Windows Server 2008, Enterprise,SP2
64-bitx86_64Windows Server 2008, Standard,RTM-SP1
64-bitx86_64Windows Server 2008, Standard,SP2
64-bitx86_64Windows Server 2008, Standard,R2 (no SP)
32-bitx86Windows 7, Enterprise (no SP)
64-bitx86_64Windows 7, Enterprise (no SP)
32-bitx86Windows 7, Professional (no SP)
64-bitx86_64Windows 7, Professional (no SP)
32-bitx86Windows 7, Ultimate (no SP)
64-bitx86_64Windows 7, Ultimate (no SP)
32-bitx86Vista, XP, 2003
Sun v1.5, v1.632 or 64-bitx86v2.4, v2.6Linux
Sun v1.5, v1.632 or 64-bitSPARCv8, v9, v10Solaris
x86v10
Sun v1.5, v1.632 or 64-bitx86v10.5 (Universal)Mac OS XaArchitecture Analysis supports JRE version 1.5.0.13 and later.
95
Architecture Analysis
Chapter 4.6. Coverity Desktop®
4.6.1. Coverity Desktop® for Eclipse on supported platforms
Coverity Desktop® for Eclipse is supported on the following platforms.
Table 4.6.1. Eclipse Plugin platform support
ProductVendor IDEand version
32 or 64-bitHost CPUHost OS or kernel versionHost OS
CoverityAnalysis for
Eclipse v3.5+
32 or 64-bitx86, x86_64
Windows XP/Windows Server2003 and higheraWindows
C/C++,Linux Kernel v2.6 and higherLinuxCoverity
64-bitx86_64OSX 10.6, 10.7 and 10.8Mac Analysis forJava
aCoverity requires a minimum service pack for some Windows versions: SP2 for Windows Server 2008, SP2 for Windows Vista,SP3 for Windows XP, SP2 for Windows 2003.
Coverity Desktop for Eclipse supports IBM JRE v1.6 and Oracle JRE v1.5, v1.6 and v1.7.
4.6.2. Coverity Desktop® for IBM Rational Team Concert (RTC) onsupported platforms
Coverity Desktop® for IBM Rational Team Concert (RTC) is supported on the following platforms.
Table 4.6.2. IBM RTC Plugin platform support
ProductVendor IDE andVersion
32 or 64-bitHost CPUHost OS VersionHost OS
Coverity Analysisfor C/C++,
Eclipse v3.5+32 or 64-bitx86, x86_64
Windows XP/Windows Server2003 and highera
Windows
Coverity Analysisfor Java
Linux Kernel v2.6 and higherLinux
aCoverity requires a minimum service pack for some Windows versions: SP2 for Windows Server 2008, SP2 for Windows Vista,SP3 for Windows XP, SP2 for Windows 2003.
Coverity Desktop for Eclipse supports IBM JRE v1.6 and Oracle JRE v1.5, v1.6 and v1.7.
4.6.3. Coverity Desktop® for ARM Development Studio 5 (DS-5) onsupported platforms
Coverity Desktop® for ARM Development Studio 5 (DS-5) is supported on the following platforms.
Table 4.6.3. DS-5 Plugin platform support
ProductVendor IDE andVersion
32 or 64-bitHost CPUHost OS VersionHost OS
CoverityAnalysis forC/C++
Eclipse v3.5+32 or 64-bitx86, x86_64Windows XP/Windows Server2003 and highera
Windows
96
ProductVendor IDE andVersion
32 or 64-bitHost CPUHost OS VersionHost OS
Linux Kernel v2.6 and higherLinuxaCoverity requires a minimum service pack for some Windows versions: SP2 for Windows Server 2008, SP2 for Windows Vista,SP3 for Windows XP, SP2 for Windows 2003.
4.6.4. Coverity Desktop® for Wind River WorkBench on supportedplatforms
Coverity Desktop® for Wind River WorkBench is supported on the following platforms.
Table 4.6.4. WorkBench Plugin platform support
ProductVendor IDE andVersion
32 or 64-bitHost CPUHost OS VersionHost OS
CoverityAnalysis forC/C++
Eclipse v3.5+32 or 64-bitx86, x86_64
Windows XP/Windows Server2003 and highera
Windows
Linux Kernel v2.6 and higherLinuxaCoverity requires a minimum service pack for some Windows versions: SP2 for Windows Server 2008, SP2 for Windows Vista,SP3 for Windows XP, SP2 for Windows 2003.
4.6.5. Coverity Desktop® for Microsoft's Visual Studio IDE on supportedplatforms
Coverity Desktop for Microsoft's Visual Studio IDE is supported on the following platforms:
Table 4.6.5. Coverity Desktop® for Microsoft's Visual Studio IDE platform
ProductVendor IDE and version32 or64-bit
Host CPUHost OS versionHost OS
Coverity Analysisfor C/C++,
Visual Studio versions 2005,2008, 2010, and 2012.
32 or64-bit
x86,x86_64
WindowsXP/Windows
WindowsCoverity Analysisfor C#
.NET 3.5 sp1 and .NET 4.0 arerequired for any Windows andVisual Studio version. b
Server 2003 andhighera
aCoverity requires a minimum service pack for some Windows versions: SP2 for Windows Server 2008, SP2 for Windows Vista,SP3 for Windows XP, SP2 for Windows 2003.bWindows update KB959209 is required.
4.6.6. Coverity Desktop® for QNX Momentics IDE on supported platforms
Coverity Desktop® for QNX Momentics IDE is supported on the following platforms.
Table 4.6.6. QNX Momentics Plugin platform support
ProductVendor IDE andVersion
32 or 64-bitHost CPUHost OS VersionHost OS
CoverityAnalysis forC/C++
Eclipse v3.5+32 or 64-bitx86, x86_64Windows XP/Windows Server2003 and highera
Windows
97
Coverity Desktop®
ProductVendor IDE andVersion
32 or 64-bitHost CPUHost OS VersionHost OS
Linux Kernel v2.6 and higherLinuxaCoverity requires a minimum service pack for some Windows versions: SP2 for Windows Server 2008, SP2 for Windows Vista,SP3 for Windows XP, SP2 for Windows 2003.
98
Coverity Desktop®
Appendix A. Appendix
A.1. Coverity Glossary
Glossary
A
Abstract Syntax Tree (AST) A tree-shaped data structure that represents the phrase structure ofconcrete input syntax (from C/C++ source code).
action In Coverity Connect, a customizable attribute used to triage a CID.Default values are Undecided, Fix Required, Fix Submitted, ModelingRequired, and Ignore. Alternative custom values are possible.
advanced triage In Coverity Connect, streams that are associated with the same triagestore always share the same triage data and history. For example, ifStream A and Stream B are associated with Triage Store 1, and bothstreams contain CID 123, the streams will share the triage values (suchas 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 updatewhen triaging a CID in a Coverity Connect project. Triage storeselection is possible only if the following conditions are true:
• Some streams in the project are associated with one triage store (forexample, TS1), and other streams in the project are associated withanother triage store (for example, TS2). In this case, some streamsthat are associated with TS1 must contain the CID that you aretriaging, and some streams that are associated with TS2 must containthat CID.
• You have permission to triage issues in more than one of these triagestores.
In some cases, advanced triage can result in CIDs with issue attributesthat are in the Various state in Coverity Connect.
See also, triage.
annotation For C/C++, a comment with specific syntax in the source code thatsuppresses a false positive or enhances a function.
For Java, the standard Java annotation format is supported for thispurpose.
C
call graph A graph in which functions are nodes, and the edges are the callsbetween the functions.
checker A program that traverses paths in your source code to find specificissues in it. Examples of checkers include RACE_CONDITION,RESOURCE_LEAK, and INFINITE_LOOP.
99
CID (Coverity identifier) An identification number assigned to a software defect. The CID allowsCoverity Connect to track which defects are new and recurring. Becausethe code containing a given defect can be part of different code basesand snapshots, Coverity Connect associates defect data, such asclassification, action, and severity, with the CID rather than the defect.The same defect can exist in multiple streams, so Coverity Connectassigns the same CID to each instance of the defect.
classification A category that is assigned to a software issue in the database. Built-inclassification values are Unclassified, Pending, False Positive,Intentional, and Bug. For Test Advisor issues, classifications includeUntested, No Test Needed, and Tested Elsewhere. Issues that areclassified as Unclassified, Pending, and Bug are regarded as softwareissues for the purpose of defect density calculations.
code annotation For C/C++, an annotation that suppresses a false positive. The analysisengine ignores events that are preceded by a code annotation, anddefects that are caused by ignored events have the Intentional statusin the Coverity Connect unless overridden. See also annotation [p. 99]and function annotation [p. 102].
For Java, the standard Java annotation format is supported for thispurpose.
code base A set of related source files.
code coverage The amount of code that is tested as a percentage of the total amountof code. Code coverage is measured different ways: line coverage,path coverage, statement coverage, decision coverage, conditioncoverage, and others.
component A named grouping of source code files. Components allow developersto view only issues in the source files for which they are responsible,for example. In Coverity Connect, these files are specified by a Posixregular expression. See also, component map.
component map Describes how to map source code files, and the issues contained inthe source files, into components.
control flow graph A graph in which blocks of code without any jumps or jump targetsare nodes, and the directed edges are the jumps in the control flowbetween the blocks. The entry block is where control enters the graph,and the exit block is where the control flow leaves.
Coverity identification (CID) An identification number assigned to a software issue. A snapshotcontains issue instances (or occurrences), which take place on a specificcode path in a specific version of a file. Issue instances, both within asnapshot and across snapshots (even in different streams), are groupedtogether according to similarity, with the intent that two issues are"similar" if the same source code change would fix them both. Thesegroups 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).
100
Appendix
Cyclomatic Complexity (CCM) The number of linearly independent execution paths through thefunctions in your source code. The higher the number, the morecomplex the function. For example, the complexity of a function withno control flow statements is 1 because there is only one possibleexecution path. However, an if statement introduces at least twopossible paths, one if the statement is true, another if it is false.
D
data directory The directory that contains the Coverity Connect database. Afteranalysis, the cov-commit-defects command stores defects inthis directory. You can use Coverity Connect to view the defects inthis directory. See also intermediate directory [p. 102].
deadcode For C/C++, code that cannot possibly be executed regardless of whatinput values are provided to the program. The DEADCODE checkercan find this code.
defect See issue.
deterministic A characteristic of a function or algorithm that, when given the sameinput, will always give the same output.
Dismissed issue Issue marked by developers as Intentional or False Positive in theTriage pane.
domain A combination of the language that is being analyzed and the type ofanalysis, either static or dynamic.
dynamic analysis Analysis of software code by executing the compiled program. Seealso static analysis [p. 104].
dynamic analysis stream A sequential collection of snapshots, which each contain all of theissues that Coverity Dynamic Analysis reports during a singleinvocation of the Coverity Dynamic Analysis broker.
E
event A defect is composed of one or more events. Events are useful inilluminating a defect's context. See also defect [p. 101].
F
false negative A defect in the source code that is not found by Coverity Analysis.
false path pruning (FPP) A method to ensure that defects are only detected on feasible paths.For example, if a then branch of a conditional cannot be reached, it isconsidered a false path and is not explored for possible defects.
false positive A potential defect that is identified by Coverity Analysis, but that youdecide is not a defect. Typically, you want to suppress these defectsfrom reappearing in future defect reports.
fixed issue Issue from the previous snapshot that is not in the current snapshot.
101
Appendix
flow-insensitive analysis A checker that is stateless. The abstract syntax trees are not visited inany particular order.
function annotation An annotation that enhances or suppresses a function model. See alsoannotation [p. 99] and code annotation [p. 100].
function model A model of a function that is not in the code base that enhances theintermediate representation of the code base that Coverity Analysisuses to more accurately analyze defects.
I
inspected issue Issue that has been triaged or fixed by developers.
intermediate directory A directory, specified with the --dir option to many commands, thatstores the analysis results before they are committed to the CoverityConnect database. See also data directory [p. 101].
intermediate representation The output of the Coverity compiler, which Coverity Analysis uses torun its analysis and check for defects. The intermediate representationof 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 do this type of analysis.
issue Coverity Connect displays three types of software issues: qualitydefects, security vulnerabilities, and test analysis issues. Some checkersfind both quality defects and potential security vulnerabilities, whileothers focus primarily on one type of issue or another. The QualityAdvisor, Coverity Security Advisor, and Test Advisor dashboards inCoverity Connect provide high-level metrics on each type of issue.
Note that this glossary includes additional entries for the various typesof issues, for example, an inspected issue, issue category, and so on.
issue category Description of the nature of the software issue. For example:
• Memory - corruptions: Out-of-bounds access
• Incorrect Expression: Evaluation order violation
issue impact A Coverity analysis generates a list of issues in your software. CoverityConnect provides the following tools to help you determine the impactof those issues:
• Defect Impact ratings. Coverity Connect assigns issues an impactrating of high, medium, or low depending on the issue's potentialrisk to the stability of the software.
• Common Weakness Enumeration (CWE), which provides furtherinformation and examples of the issue type.
102
Appendix
K
killpath For Coverity Analysis for C/C++, a path in a function that abortsprogram execution. See<install_dir_sa>/library/generic/common/killpath.cfor the functions that are modeled in the system.
For Coverity Analysis for Java, a modeling primitive used to indicatethat execution terminates at this point, which prevents the analysisfrom continuing down this execution path. It can be used to model anative method that kills the process, like System.exit, or tospecifically identify an execution path as invalid.
L
latest state A CID's state in the latest snapshot merged with its state from previoussnapshots starting with the snapshot in which its state was 'New'.
local analysis An analysis for defects within a single procedure or function that doesnot use interprocedural analysis [p. 102].
M
model For Coverity Analysis for C/C++, a representation of each method inthe application that is used for interprocedural analysis, created as eachfunction is analyzed. For example, the model shows which argumentsare dereferenced, and whether the function returns a null value.
For Coverity Analysis for Java, a representation of each method in theapplication that is used for interprocedural analysis. For example, themodel shows which arguments are dereferenced, and whether thefunction returns a null value. Models are created as each function isanalyzed.
N
native build The normal build process in a software development environment thatdoes 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 throughthe Triage pane. Coverity Connect identifies the owner of issues notyet assigned to a user as Unassigned.
P
postorder traversal The recursive visiting of children of a given node in order, and thenthe visit to the node itself. Left sides of assignments are evaluated afterthe assignment because the left side becomes the value of the entireassignment expression.
103
Appendix
project In Coverity Connect, a specified set of related streams that provide acomprehensive view of issues in a code base.
R
resolved issues Issues that have been fixed or marked by developers as Intentional orFalse Positive through the Coverity Connect Triage pane.
run In Prevent releases 4.5.x or lower, a grouping of defects committed tothe Coverity Connect. Each time defects are inserted into the CoverityConnect using the cov-commit-defects command, a new run iscreated, and the run ID is reported. See also snapshot [p. 104]
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 practicesto eliminate system crashes, corruption, escalation of privileges, ordenial of service. See also tainted data [p. 105].
severity In Coverity Connect, a customizable property that can be assigned toCIDs. 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 beprotected from tainted data. Examples are array subscripting,system(), malloc().
Coverity Analysis for Java: Any operation or function that must beprotected from tainted data. Examples are array subscripting and theJDBC 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 duringdevelopment.
Snapshots contain the results of an analysis. A snapshot includes boththe issue information and the source code in which the issues werefound. Coverity Connect allows you to delete a snapshot in case youcommitted faulty data, or if you committed data for testing purposes.
source An entry point of untrusted data. Examples include environmentvariables, command line arguments, incoming network data, and sourcecode.
static analysis Analysis of software code without executing the compiled program.See also dynamic analysis [p. 101].
store A map from abstract syntax trees to values. This map can be used toimplement an abstract interpreter, used in flow-sensitive analysis.
stream A sequential collection of snapshots. Streams can thereby provideinformation about software issues over time and at a particular pointsin development process.
104
Appendix
T
tainted data Any data that comes to a program as input from a user. The programdoes not have control over the values of the input, and so before usingthis data, the program must sanitize the data to eliminate systemcrashes, corruption, escalation of privileges, or denial of service. Seealso sanitize [p. 104].
triage The process of setting the states of an issue in a particular stream, orof issues that occur in multiple streams. These user-defined statesreflect 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 whomthe issue is assigned, and so forth. These details provide trackinginformation for your product. Coverity Connect provides a mechanismfor you to update this information for individual and multiple issuesthat exist across one or more streams.
See also advanced triage.
U
unified issue An issue that is identical and present in multiple streams. Each instanceof an identical, unified issue shares the same CID.
uninspected issues Issues that are as yet unclassified in Coverity Connect because theyhave not been triaged by developers.
unresolved issues Defects are marked by developers as Pending or Bug through theCoverity Connect Triage pane. Coverity Connect sometimes refers tothese 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 securitychecker. For example, USE_AFTER_FREE and UNINIT are listedas such in the Issue Kind column of the View pane. All C/C++security checkers are also treated as quality checkers by CoverityConnect. For details, see the Coverity® 6.6 Checker Reference.
• When different instances of the same CID are triaged differently.Within the scope of a project, instances of a given CID that occurin separate streams can have different values for a given triageattribute if the streams are associated with different triage stores.For example, you might use advanced triage to classify a CID as aBug in one triage store but retain the default Unclassified settingfor the CID in another store. In such a case, the View pane ofCoverity Connect identifies the project-wide classification of theCID as Various.
Note that if all streams share a single triage store, you will neverencounter a CID in this triage state.
105
Appendix
view Saved searches for Coverity Connect data in a given project. Typically,these searches are filtered. Coverity Connect displays this output indata tables (located in the Coverity Connect View pane). The columnsin these tables can include CIDs, files, snapshots, checker names, dates,and many other types of data.
106
Appendix
A.2. Coverity Legal Notice
107
Appendix
Coverity Legal Notice
The information contained in this document, and the Software provided by Coverity, are the proprietaryand confidential information of Coverity and its licensors, and are supplied subject to, and may be usedonly by Coverity customers in accordance with the terms and conditions of a license agreement previouslyaccepted by Coverity and that customer. Coverity's current standard end user license terms and conditionsare contained in the CoverityLicense.pdf file located at <install_dir>/doc/.
Portions of the product described in this documentation use third-party material. Notices, terms andconditions, and copyrights regarding third party material may be found in the<install_dir>/doc/licenses directory.
Customer acknowledges that the use of Coverity Software may be enabled by authorization keys suppliedby Coverity for a limited licensed period. At the end of this period, the authorization key will expire. Youagree not to take any action to work around or override these license restrictions or use the Software beyondthe licensed period. Any attempt to do so will be considered an infringement of intellectual property rightsthat may be subject to legal action.
U.S. GOVERNMENT RESTRICTED RIGHTS: The Software and associated documentation are providedwith Restricted Rights. Use, duplication, or disclosure by the U.S. Government is subject to restrictionsset forth in subparagraph (c)(1) of The Rights in Technical Data and Computer Software clause at DFARS252.227-7013 or subparagraphs (c)(1) and (2) of Commercial Computer Software - Restricted Rights at48 CFR 52.227-19, as applicable.
The Manufacturer is: Coverity, Inc. 185 Berry St., San Francisco, California 94107.
Coverity Static Analysis is protected by U.S. Patent No. 7,340,726.
Trademark Statement
Coverity, the Coverity logo, a higher code, and Coverity Certified are trademarks or registered trademarksof Coverity, Inc. in the U.S. and other countries.
Coverity’s trademarks may be used publicly only with permission from Coverity. Fair use of Coverity’strademarks in advertising and promotion of Coverity’s products requires proper acknowledgement.
Microsoft and Visual Studio are trademarks or registered trademarks of Microsoft Corporation in the UnitedStates 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 oftheir respective owners.
"MISRA", "MISRA C" and the MISRA triangle logo are registered trademarks of MISRA Ltd, held onbehalf of the MISRA Consortium.
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 Software contains open source or community source software (“Open Source Software”) providedunder separate license terms (the “Open Source License Terms”), as described in the applicable licenseagreement under which this Software is licensed (“Agreement”). The applicable Open Source License
108
Appendix
Terms are identified in a directory named “Licenses” provided with the delivery of this Software. For allOpen Source Software subject to the terms of an LGPL license, Customer may contact Coverity [email protected] and Coverity will comply with the terms of the LGPL by delivering toCustomer the applicable requested Open Source Software package, and any modifications to such OpenSource Software package, in source format, under the applicable LGPL license. Any Open Source Softwaresubject to the terms and conditions of the GPLv3 license as its Open Source License Terms that is providedwith this Software is provided as a mere aggregation of GPL code with Coverity’s proprietary code, pursuantto Section 5 of GPLv3. Such Open Source Software is a self-contained program separate and apart fromthe Coverity code that does not interact with the Coverity proprietary code. Accordingly, the GPL codeand the Coverity proprietary code that make up this Software co-exist on the same media, but do not operatetogether. Customer may contact Coverity at [email protected] and Coverity will comply withthe terms of the GPL by delivering to Customer the applicable requested Open Source Software packagein source code format, in accordance with the terms and conditions of the GPLv3 license. No Coverityproprietary code that Coverity choses to provide to Customer will be provided in source code form; it willbe provided in executable form only. Any Customer changes to the Software (including the Open SourceSoftware) will void all Coverity obligations under the Agreement, including but not limited to warranty,maintenance services and infringement indemnity obligations.
109
Appendix