CodeChecker is a static analysis infrastructure built on the LLVM/Clang
Static Analyzer toolchain, alternative tool for
scan-build in a Linux or
macOS (OS X) development environment.
The product system allows a single CodeChecker server to serve multiple separate result databases, named "products", under the same IP address and authentication domain.
After enabling the administrative actions by clicking on the
Show administration button in the top right corner, click Add new product,
then fill the form presented. The values that need to be filled here are the
same as the arguments for CodeChecker cmd products add.
These buttons are visible only for Super Users.
If the product creation is successful, the window will disappear and the product will appear in the product list.
Editing a product is done through the pencil icon, which is visible when administrative actions are enabled. This window lets you edit the product's configuration.
Products can be deleted by clicking on the red trash bin. This way the product is only unmounted from the server (losing access control data and connection), but no analysis results are deleted.
- Server-wide permissions can be edited by clicking Edit global permissions.
- Product-level permissions can be edited by clicking the edit icon for the product you want to configure the permissions.
From the dropdown, select the permission you want to configure. The two lists show the users and groups known to the system - if a tick is present in its row, the given user or group has the permission directly granted. (Users who only have a certain permission through permission inheritance are not shown with a tick.)
Only the permissions you have rights to manage are shown in the dropdown.
You can edit multiple permissions opening the window only once. Simply tick or untick the users/groups you want to give the permission to or revoke from them. Clicking OK will save the changes to the database.
List page contains the analysis runs available on the server under the selected product.
You can do the following on this page:
The meaning of the table columns:
- Diff - In this column you can select two runs (baseline and newcheck) which will be compared to each other by click on the Diff button.
- Name - Name of the run.
- Number of unresolved reports - Number of non unique reports excluding Resolved, False positive and Intentional reports.
- Storage date - Storage date of the runs.
- Analysis duration - Duration of the analysis.
- Check command - By clicking on Show text the check command will be shown in a pop-up window.
- Detection status - Detection statuses are calculated based on the detection status values from the previous store where the reports are stored again with the same run name. When storing the results of a run from scratch then each report will have detection status of New.
- Version tag - Latest version tag of the run.
- Delete - In this column you can select multiple runs which will be removed by clicking on the Delete button.
You can filter runs by run name using the input box above the run list table. The filter is case insensitive and doing a substring matching. If we start typing some phrase in this input box, the list are being filtered automatically.
Calculates difference between two analyses of the project, showing which bugs have been fixed and which are newly introduced.
You can delete multiple runs by selecting them and clicking on the Delete button. It will remove the run and all related data from the database.
It is possible to change the order of the runs by clicking on a cell at header of the run list table. For example, you can sort the run list by the number of bugs or the run name.
A statistical overview can be seen under "Checker statistics" panel. Here you can see multiple tables:
- Checker statistics table shows the number of reports by checkers based on some attributes of the report like severity, and report status.
- Severity statistics table shows the number of report by severity levels.
We can get statistics only for specified runs, files, checker names etc. by using the filter bar beside the statistic tables. For more information check the report filtering section.
The same bug may appear several times if it is found on different execution paths, i.e. through different function calls. By checking Unique reports a report appears only once even if it is found on several paths. By default uniqueing is enabled for statistics.
If you select a run at the list of runs view, you get to this page. This page lists the analysis result for the given run.
When opening the bug list view under "All reports" tab or by clicking a specific run or by opening "diff view" between two runs then the following filter options are available:
- Unique reports - You can uniqueing the reports by checking this.
- Report hash - Every report has a unique (hash) identifier called Report Identifier (RI) which can be filtered by using this input box.
- Baseline
- Run name - You can select one or more run names. The result list is restricted on the findings in these runs. By selecting a specific run in the "runs" view this field is filled by default. In "All reports" tab no run is selected in which case the reports from all runs are visible.
- Run tag - When runs are stored in update mode (i.e. on the same run name), then the specific runs can be tagged in order to be easier to identify them. By this field you can select the reports found during a specific run event.
- Newcheck
- Run name - Here you can select multiple run name which you want to compare against the baseline filter set.
- Run tag - Here you can select multiple run tags which you want to compare against the baseline filter set.
- Diff type - Here you can set if you'd like to see the bugs which appear only in the Baseline, Newcheck or both.
- Review status - You can select the reports with the given review status to check only False positive, Unreviewed, etc. reports.
- Detection status - You can select the reports with the given detection status to check only Unresolved, Resolved, etc. reports.
- Severity - The nature of the bugs is sorted in different severity levels. For example, a division by zero or a null pointer dereference is more serious than an unused variable. By this field you can select the reports on the given severity levels.
- Detection date - A date interval can also restrict the list of displayed bug reports. In this field you can choose the date of detection or fixing.
- File path: You can choose a set of files to restrict the list of bug reports.
- Source component - Here you can select multiple source components which are named collection of directories specified as directory filter.
- Checker name - If you are interested in specific type of bugs then here you can choose them.
- Checker message - The static analysis tools provide a message to indicate the reason of a specific bug. This message is also filterable.
Run name may contain * quantifiers which matches any number of characters
(zero or more). So if you have run_1_a_name, run_2_b_name, run_2_c_name,
run_3_d_name then run_2* will select run_2_b_name and run_2_c_name.
When you select a filter option on any field then a number indicates on the right side of the option the number of reports which belong to that specific option. If the report count could not be determined this value will be N/A.
Filtered reports can be removed by clicking on the Remove filtered reports button at the top of the filter bar.
!!!WARNING!!! Once you have removed filtered reports it can not be undone. Please make sure that you want to remove all filtered results before clicking on this button.
Filter options can be cleared separately by clicking on the trash icon beside a filter or all filters can be cleared by using Clear All Filters button at the top of the filter bar.
At the top of the filter panel there is a "Unique reports" checkbox. This narrows the report list to unique bug. The same bug may appear several times if it is found on different control paths, i.e. through different function calls or in multiple runs. By checking "Unique reports" a report appears only once even if it is found on several paths.
In diff mode you can calculate the difference between multiple analyses of the project, showing which bugs have been fixed and which are newly introduced or which can be fined in all runs.
At the Baseline filter section you can select the run names and run tags against which you want to check the difference.
At the Newcheck filter section you can select the run names and run tags which you want to compare against the Baseline runs and run tags.
Reports can be assigned a review status of the following values:
- Unreviewed (default): Nobody has seen this report.
- Confirmed: This is really a bug.
- False positive: This is not a bug. Before marking a bug false positive you should read the false positive how to.
- Intentional: This report is a bug but we don't want to fix it.
For more information see.
The detection status is the state of a bug report in a run. When storing the results of a run from scratch then each report has detection status New. When the reports stored again with the same run name then the detection status can change to one of the following options:
- Resolved: when the bug report can't be found after the subsequent storage.
- Unresolved: when the bug report is still among the results after the subsequent storage.
- Reopened: when a resolved bug appears again.
We are mapping checker names to different severity levels:
- Unspecified
- Style: (E.g. modernize-raw-string-literal, modernize-use-auto, etc.)
- Low (E.g. deadcode.DeadStores, misc-unused-parameters, etc.)
- Medium: (E.g. unix.Malloc, core.uninitialized.Assign, etc.)
- High: (E.g. core.DivideZero, core.NullDereference, cplusplus.NewDelete, etc.)
- Critical
Source components are named collections of directory filters. Source components can be managed only by administrators after clicking on the pencil icon at the Source component filter.
A pop-up window will be opened where you can add, edit or remove existing source components.
At this page you can navigate between reports and check the errors what CodeChecker found.
This page has four main parts:
Report Navigation Tree shows the found reports at the currently opened file. The reports are grouped by the severity level. You can navigate between them by clicking on a node in the tree.
Button Pane contains several items which help you to change or get some
property of the currently opened report.
Show Documentation button shows the documentation of the actual checker which
identified by the currently opened report.
Reports can be assigned a review status of Unreviewed, Confirmed, False
positive, Intentional, along with an optional comment on why this status was
applied. We can change the review status from the default
Unreviewed option
to something else in the report details view above the file view.
If you changed the review status, you can optionally explain the reason why
you changed it.
If somebody has already changed the review status from the default one, you can
see extra information (who changed the review status, when and why) beside
the review status selector by hovering on the message icon. This message icon is
hidden by default if nobody has changed the review status.
Several reports may belong to a specific bug if the but itself can be reached on different control paths. In the Bug viewer you can check whether the selected bug is available on a different path.
Some checkers are able to follow the execution path along the control flow of the program. If a bug appears on any of these paths, then CodeChecker is able to present the full path on which this so called symbolic execution reached the place of error. This path can be checked in this bug path view.
Bug reports can be commented. You can add new comments, edit () and delete () them.
The author of the comment will be the currently logged in user. If the user is not logged in, the author of the comment will be Anonymous.
Comments are shown for the same report found in multiple runs.
When selecting a run then a "Run history" tab appears next to the Bug overview. In this window you can check the specific run events which happened during a storage process under the same run name. This way you can list the reports' state in the selected run event.
