[GSOC 2019] Apply the Clang Static Analyzer to LLVM-based Projects

Hi community,

I am Edward, an Information Engineering student from Hong Kong, I am finishing my proposal for the Clang Static Analyzer improvements for GSOC 2019.
After the discussion with Artem, I have investigated on one of the most common false positives/undocumented error, related to the placement new operator. Apart from this weird error, I would like to gather the debug experience from Clang developer on the potential false positives that I can take a look and work on.

Please find the following attached link for the report on placement new operator as an example
https://llvm.org/reports/scan-build/report-HexagonMCCompound.cpp-getCompoundInsn-105-1.html#EndPath

I have also attached the link to my content part of the proposal, kind comments are very welcomed!
https://docs.google.com/document/d/1f1X5QufICiQRbIqoKm83JP8CHeYZTj7cK57q-Oeaw1o/edit?usp=sharing

Thank you for spending time on reading my questions and proposal, I am looking forward to your kind reply.

Many thanks,
Edward Hui

Hi,

You made it pretty far! I added a few comments inline on the doc.

The common technique to debug false positives, crashes and mis-modeling is to dump the Exploded Graph in graphviz .dot format, as described in https://clang-analyzer.llvm.org/checker_dev_manual.html#visualizing , and use it to isolate the line of code that was modeled incorrectly. These dumps are usually huge but searchable. You usually start from the bottom of the graph (much like when reading the Analyzer warning) and see if the ProgramState dump contains anything that looks suspicious: an impossible/incorrect value of an expression or of a variable, etc. Then you search the graph for the place in which the incorrect binding has first appeared. If the rest of the state at this place looks correct, you're done; otherwise, pick that other incorrect item and search again.

Once you're done with it, you'll be pointed to a specific ExprEngine visit function or a specific checker callback (if the node is tagged with a checker tag) that you can debug with a debugger to see why does it cause the incorrect item to appear in the program state.

Apart from false positives / crashes / mis-modelings, there are also bug reporter problems (i.e., the warning is a true positive, but it's impossible to understand by looking at the report). There aren't any tools to debug those so far, so you usually have to use the debugger (or prints) to understand how notes are added. But, luckily, warnings are emitted much less often than transfer functions are applied, so these are relatively easy to understand and debug.