Contributed by Jay Rajput, ELISA 2020-2021 Mentee
The following is a brief report of my project carried out as a part of the ELISA/LFX mentorship program.
The primary goal of the mentorship is to extend the Codechecker report converter to support a variety of tools such as:
- Coccinelle
- Smatch
- Sphinx
- Kernel-Doc
- Sparse
Motivation
Many developers contribute to the Linux kernel. And these kernel developers are not exempted from typical programming errors in their patches, such as null pointer referencing, array buffer overflow. Thus, the kernel community has developed some code analyzers, such as sparse, coccinelle and smatch, for reporting such potential error patterns.
The tools mentioned above are some of the well-known tools for analyzing the code of Linux kernel. These tools however only print the warnings and errors on the command-line interface.Below is the output of some example:
| arch/x86/kernel/signal.c:338:9: warning: incorrect type in argument 1 (different address spaces)arch/x86/kernel/signal.c:338:9: expected void const volatile [noderef] __user *ptrarch/x86/kernel/signal.c:338:9: got unsigned long long [usertype] *arch/x86/kernel/signal.c:338:9: warning: cast removes address space ‘__user’ of expressionarch/x86/kernel/signal.c:338:9: warning: cast removes address space ‘__user’ of expressionarch/x86/kernel/pci-dma.c:20:26: warning: symbol ‘dma_ops’ was not declared. Should it be static?arch/x86/kernel/pci-dma.c:27:5: warning: symbol ‘panic_on_overflow’ was not declared. Should it be static?arch/x86/kernel/pci-dma.c:31:5: warning: symbol ‘iommu_merge’ was not declared. Should it be static? |
It is tedious for developers to look up and keep track of all the errors through the text file/terminal. Manually searching the line of the error also becomes a tedious job. Furthermore, sending the findings or comments to another developer is not feasible. Thus, it becomes very difficult for developers to keep track of all the errors. CodeChecker offers a nice and convenient web interface for viewing all the errors and even giving them some tags such as confirmed, false positive, etc.
CodeChecker’s report converter tool provides an interface for viewing all the reports produced by the code-analyzing tools in a nice and simple web interface. It also provides the functionality to comment and mark the bugs as confirmed, false positive, etc. Thus, I wanted to extend the report converter to the tools mentioned above and also implement the functionality for importing and exporting the changes to and from CodeChecker.
Report Converters for Analyzer Tools
My first and primary task was to create report converters for the tools mentioned above. These report converters would parse the output of tools, using regex into the format:
| File Path | Line Number | Column | Error Message | Checker Name |
Once the report converter parses the output file of the tools it stores them into plist files which can be opened and viewed into the browser. All the plist files are stored in a folder specified by the user while running the report converter.
CodeChecker also provides a feature to store these plist files into the CodeChecker server and then we can perform multiple operations on the reports like marking the status( confirmed, false positive, etc) and adding comments on each bug.
Importer and Exporter for CodeChecker
The CodeChecker command-line interface provides a variety of options for listing, filtering all the runs/results present in the CodeChecker server. I have added two more commands to the CodeChecker CLI for Importing and Exporting the results to and from the CodeChecker Server.
The Export command lets the user export the findings i.e comments and review the status of one or more reports specified by the user. Below is the sample output of the reports:
| { “comments”: { “c54004ae9ecfb34b396b46d9e08c4291”: [ { “id”: 7, “author”: “Anonymous”, “message”: “This is a confirmed Bug here”, “createdAt”: “2020-11-28 00:05:02.034035”, “kind”: 0 }, { “id”: 6, “author”: “Anonymous”, “message”: “I am doubtful about this bug”, “createdAt”: “2020-11-28 00:01:48.190914”, “kind”: 0 } }, “reviewData”: { “00eab39f7bb399d446e0794025ab3958”: { “status”: 1, “comment”: “This is for the exporter function testing”, “author”: “Anonymous”, “date”: “2020-12-20 23:01:02.669476” }, }} |
The Importer command is used for importing the comments and review statuses sent by another user into CodeChecker Server. For importing the comments, for each comment, we check if the date, kind, and the message of the existing comment in the server and the incoming report. If any of them is different, we replace the existing comment with the incoming comment. Similarly, for review status, if the date of the review status is different, then we update the review status in the server with the incoming review.
Use Case of Review Exchange
Consider there are two users of your System, John, and Maria. Both of them have the output of Coccinelle on the Linux kernel.
They run the report converter of coccinelle on the output as:
| report-converter -t coccinelle -o ./codechecker_coccinelle_reports ./coccinelle_reports.out |
The details of how to use the report converter of all tools can be found in Report Converter Readme.
They store the findings into the Codechecker server using the command:
| CodeChecker store ./codechecker_coccinelle_reports -n coccinelle |
Assume that there are 10 errors in coccinelle with report ids 1 to 10. John performs the following changes:
- Marks report 1 as false positive and comments “This is not an actual bug”
- Marks report 2 as Confirmed.
- Comments on report 3 “I am not sure about the status of this bug”
Maria makes the following changes in this copy on his machine:
- Marks report 3 as Confirmed and comments “This is a confirmed bug”
- Comments on report 4 “This error needs to be handled”
Now, John runs the export command and obtains the json with the name coccinelle.json
| CodeChecker cmd export -n coccinelle 2>/dev/null | python -m json.tool > coccinelle.json |
John sends the obtained file to Maria via email or any other communication medium. Maria downloads this file and imports the findings into his CodeChecker server:
| CodeChecker cmd import -i coccinelle.json |
Now, the reports in Maria’s server will be:
| Report 1:Tag: False PositiveComment: This is not an actual bugReport 2:Tag: ConfirmedReport 3:Tag: ConfirmedComments: [I am not sure about the status of this bug, This is a confirmed bug]Report 4:Comment: This error needs to be handled |
Pull Requests
- Coccinelle Parser: Coccinelle report converter tool for parsing coccinelle output of kernel sources.
https://github.com/Ericsson/codechecker/pull/2949
https://github.com/Ericsson/codechecker/pull/2955
https://github.com/Ericsson/codechecker/pull/2979
- Smatch Parser: Smatch report converter tool for parsing Smatch output of kernel sources.
https://github.com/Ericsson/codechecker/pull/2968
https://github.com/Ericsson/codechecker/pull/2980
- Kernel-Doc Parser: Kernel-Doc report converter tool for parsing Kernel-Doc output of kernel sources.
https://github.com/Ericsson/codechecker/pull/2981
- Sphinx Parser: Sphinx report converter tool for parsing Sphinx output of kernel sources.
https://github.com/Ericsson/codechecker/pull/3017
- Fix CodeChecker’s cmd results: Comments in the cmd results command were not fetched properly and even showed empty strings in some cases. Added a separate comments section to the details of the results command.
https://github.com/Ericsson/codechecker/pull/3075
- Importer & Exporter command: Exporter command for exporting the comments and review statuses for given or all runs into a json file. Importer command for importing the findings sent by another developer in a json file.
https://github.com/Ericsson/codechecker/pull/3116
- Sparse Parser: Sparse report converter tool for parsing Sparse output of kernel sources.
https://github.com/Ericsson/codechecker/pull/3160
Future Work
- Currently, the import and export commands of CodeChecker are limited only to the Command Line Interface. I would like to implement a feature to make these available in the Web Interface as well.
- I would like to extend CodeChecker’s report converter tools to provide proper warning classes for all the report converters.
- I would like to add support for multiple users within a single instance of CodeChecker coming to different assessments and then moderating or reviewing them in some controlled way.
Acknowledgment
I would like to thank my mentor Lukas Bulwahn for giving me this opportunity and helping me come up with workflows and ideas for fulfilling my goals. My heartfelt gratitude towards the maintainers of CodeChecker especially Márton Csordás for being patient with me during code reviews and providing his valuable feedback.