Tips for managing Klocwork Insight
- Klocwork services fail to start as Windows services
- Analysis configuration and checker filtering
- Trying to start MySQL as root
- Java Out of Memory Errors
- Custom compiler configuration
- Releasing stuck licenses
- Usernames are case-sensitive
- Making sure your Klocwork Desktop floating license is released
- Excluding some libraries from analysis
Some Klocwork administrators have experienced a problem where the Klocwork services are set to start automatically whenever the server reboots. When the server restarts, only one of the services starts, while the database and server services fail to start.
Remember that you can always start the services manually with: kwservice start
If the services are running on Windows 7, it may be that the machine is busy during the boot process. Try using the Windows Delayed start. Control Panel>Administrative Tools>Services and locate all the Klocwork services and change their "Startup type" (in the "General" tab of each Klocwork service) from "Automatic" to "Automatic (Delayed Start)"
The issue may be that the .NET framework does not handle system shutdown properly, so the Klocwork Database service does not shutdown properly and appears to hang on system startup since it has to go through a crash recovery process. This has been fixed as of Insight 9.5 SR1.
This may occur if the projects-root has been moved. See the following documentation: Ensuring that the Klocwork servers start in the new projects root
You may want to confirm which checkers are currently in use, and you may want to filter your list of issues, based on checkers. What's the difference, and how do you do this?
There are 2 separate issues here. There is checker configuration (controlling which checkers are turned ON or OFF when the analysis is run) and there is checker filtering (aka, filtering Issues found by checker type).
In configuration, if a checker is ON then it is run (executed) by the analysis engine and it may then find Issue(s). If a checker is OFF, then it's NOT run and there won't be any Issues found for that checker.
Then we have a Taxonomy, which is a name for a 'list' of checkers. The Taxonomy filters the total set of Issue(s) and just reports results for the checkers in the Taxonomy set that actually have results (think of this as a filtered view of Issues). For Insight, CERT and CWE are simply Taxonomies that filter Issues to show only the issues that pertain to CERT and/or CWE. MISRA on the other hand, is an add-on package of checkers (the 2 packs add some 260 extra checkers to Klocwork). They also have their own Taxonomies. The packs are free but you have to download them from my.klocwork.com and then install them (learn more at: http://www.klocwork.com/products/documentation/current/Deploying_custom_...).
To see which checkers are ON/OFF or associated with a particular Taxonomy, you use KMC (in Insight 9.2) or Klocwork Review (in Insight 9.5). Edit the file 'problems_default.pconf.xml' either with the advanced editor or directly by using the 'kwconfigeditor' command. This GUI will show you what's ON/OFF and how the Taxonomies are organized. Checker packages are installed to the Klocwork 'projects_root' instance so they're global to a given Klocwork Server instance. Checker config and Taxonomy are 'defaulted' across the same instance but may be overridden by each Project and may be changed between each Build. Anything done at the Klocwork Server instance will flow out to any connected desktops (they'll inherit from the Server) but the developer may override at their desktop only if they want.
The issue of starting MySQL as root is raised regularly in forums and through Customer Support. The Klocwork Database Server refuses to start if started with the root user account. You will see an entry such as
[ERROR] Fatal error: Please read "Security" section of the manual to find out how to run mysqld as root!
in the <projects root>/logs/database.log file.
mysqld will refuse to start, by default, when run as root, because this poses a security risk. Any user with the MySQL FILE privilege will be able to create files as root through the mysql server. For example a user with FILE privilege could create a file ~root/.bashrc containing entries that could be used to do pretty much anything to the system, which is why mysqld will not start when run with the root account unless mysqld is started with the --user=root option, and we do not provide a way through kwservice to specify this option. See the following article for details.
Recently, Klocwork Customer Support has seen a number of issues relating to Java Out of Memory errors when running Klocwork builds with large projects, or projects containing a large number of issues.
The error is an exception caused by “java.lang.OutOfMemoryError: Java heap space”. Many of the Klocwork tools run in Java and by default, we try to restrict the amount memory each JVM process can use for a particular tool to a reasonable amount.
If you are experiencing this error and your build requires a bit of extra memory, you can easily modify these defaults by changing the -Xmx option values in the <klocwork_install>/config/java_wrappers.conf configuration file.
There are three specific processes run during the analysis and database loading stages that can sometimes require additional memory, specifically: kwpropagate, kwdbload, and finally kwinspect. Detailed information is provided for these three executables below; however you can adjust Java memory allocation for a variety of executables as indicated in our online documentation, Java Memory Problems when Running Klocwork Applications.
The propagation step is where additional JVM memory is sometimes needed. This step involves properly categorizing and matching issues detected in the current build with any issues detected in previous builds of the project in order to display correct trending and statistics (existing, recurred, new, etc). With very large projects and large numbers of detected issues the propagation step requires large amounts of memory to successfully complete, especially for a subsequent build analysis of a project. The default value of -Xmx for kwpropagate is -Xmx1G, but recommended values for cases where the propagation step fails are -Xmx2G or -Xmx2500M.
The database loading step occurs after propagation and may require additional memory for larger builds, as it uploads the results of the analysis and propagation to the Klocwork database server. The default memory setting is -Xmx512M, but values between -Xmx1G and -Xmx1500M are sometimes needed for this step to successfully complete.
Kwinspect (not to be confused with our code review tool, Inspect)
The reports-generation stage is run with kwinspect and occurs before propagation and database loading. Memory issues with this step are less frequent. The default memory setting here is -Xmx1G. You may require a higher value of -Xmx1500M or in rare cases, 2G or higher for this step to be successful.
Finally, one important point about adjusting these memory values - you should only give as much memory to these processes as needed because trying to reserve too much memory can prevent the JVM from initializing at all and cause an error of “Could not reserve enough space for object heap”. Start with smaller values and work your way up until the process can successfully complete. If you do encounter this JVM initialization error, try a slightly lower value.
We have found that many customers find custom compiler configuration a daunting and frustrating process, and so as of Klocwork Insight 9.2, we no longer advise that you try to configure custom compilers yourself. Instead, we are committed to providing this configuration for you for any compiler that you need.
For Klocwork Insight 9.2 or greater, just send along the compiler name and the exact version, along with a trace file from kwinject and we should be able to provide compiler configuration files for you within 2 business days. Details on how to use kwinject to generate a trace file are here:
See Alen Zukich's blog on Compiler configuration.
A stuck license is a checked-out license that has not been returned to the pool of available licenses when one of the Klocwork tools terminates unexpectedly. If a Klocwork tool has one or more licenses checked out and it terminates, these licenses may not be checked back in automatically.
To release a stuck license, use the FLEXlm tool lmremove. It is installed with the Server package.
From <server_install>/3rdparty/bin, run:
lmremove -c <license_file_list> <feature> <user> <user_host> <display>
- <license_file_list> specifies the license file(s)
- <feature> is the name of the feature checked out by the user
- <user> is the name of the user whose license you are releasing
- <user_host> is the name of the host the user is logged into
- <display> is the name of the display where the user is working
Note: The user, user_host and display information must be obtained from the output of lmstat. See Finding out how many licenses are in use.
lmremove removes all instances of user on user_host and display from usage of feature.
Note that in addition to releasing a stuck license, lmremove starts, but does not override, the license's linger time.
Case-sensitivity can appear to behave inconsistently, depending on the operating system and the application being used. Understanding the different behaviors allows you to have a predictable login experience.
If Klocwork Server is running on a Windows machine, users who log in to Klocwork Review/Code Review will have a license checked out using the lowercase form of their username. Other tools such as Klocwork Architect will not change the case of the username (obtained from the O/S), and hence a second license is checked out.
If you are running it on a non-Windows machine, users who log in to Review/Code Review will have a license checked out using the case as entered in the Login dialog. As above, other tools will use the user name as obtained from the O/S.
- When logging into a Windows machine, use a lowercase username.
- When logging into a non-Windows machine, match the letter case used by your O/S.
The Klocwork Desktop application still consumes a floating user license after the user closes the interface (for approximately 10 minutes). To ensure that the license is released immediately, use File > Exit on the Klocwork Desktop File menu, as using the window close button (x) only closes the user interface, and not the process behind it. You can also exit completely using the system tray, by right-clicking on the Klocwork Desktop icon on the system tray and choosing the Exit menu item.
It is possible to exclude some libraries from analysis, since some applications use a lot of 3rd party libraries that are not under our control, and that generate a lot of errors that we can't or don't plan to fix. Libraries are very important to have as part of the analysis, and you always want to keep them so Klocwork has the full context of your system. But as you may never fix the 3rd party defects, we suggest you go to Klocwork Review, scope down to the 3rdparty code and "edit all" so you can change the status to "Ignore" or whatever you want. Going forward you will never see those issues again.