[llvmlinux] [GSoC: Static analysis] Report 0

[Eduard Bachmakov]

Hey Marcelo!

You can find some instructions on the wiki page I mentioned earlier.
I'm in the process of integrating the checking into the build system
though. Once that's pushed it should become trivial for anyone to run
these checks and we can start discussing the results and working on
increasing sensitivity and specificity. I'm definitely looking forward
to that :-).

According to http://clang-analyzer.llvm.org/checker_dev_manual.html ,
"Currently, the analyzer only reasons about one procedure at a time
(no inter-procedural analysis)."

However, according to
http://clang-analyzer.llvm.org/release_notes.html there should be some
degree of inter-procedural analysis (probably limited scope/no pun
intended)

On Mon, Jun 17, 2013 at 3:54 PM, Marcelo Sousa <marceloabsousa at gmail.com> wrote:
> Hi again,
>
> I'm looking at your reports (which are quite nice) and an obvious way of
> reducing false positives is to do an interprocedural analysis. Do you know
> if it's possible to set that up with the clang-analyzer?
>
> Regards,
> Marcelo
>
>
> On Mon, Jun 17, 2013 at 2:43 PM, Marcelo Sousa <marceloabsousa at gmail.com>
> wrote:
>>
>> Hey Eduard,
>>
>> Awesome! Can you share a script or a build process where I can start
>> plug-in checks?
>>
>> ~750 of nullptrs is very good! If we can come up with a good way of
>> handling false positives and find say ~20/30 real bugs with the
>> infrastructure and the already default checks, it would be quite valuable.
>> Is there a meeting to discuss your findings? I would like very much to
>> collaborate with you guys in this project.
>>
>> Regards,
>> Marcelo
>>
>>
>>
>> On Mon, Jun 17, 2013 at 2:33 PM, Eduard Bachmakov <e.bachmakov at gmail.com>
>> wrote:
>>>
>>> Hey guys, let's get this party started ;-).
>>>
>>> First off, you will be able to get the current status in the wiki at
>>> http://llvm.linuxfoundation.org/index.php/Static_Analyzer
>>>
>>> Demo.
>>> After some tweaking I was able to run the analyzer (default settings).
>>> I didn't time the build but subjectively it took 3+ times as long. If
>>> you want to take a look, the results are at
>>> https://dl.dropboxusercontent.com/u/9902213/2013-06-17-1.tar.xz
>>> (careful, 50M compressed, 1.9G uncompressed). Open index.html in your
>>> favorite browser.
>>>
>>> Stats (on demo).
>>> For x64 the analyzer finds ~4500 issues, more than half being dead
>>> assignments such as "Value stored to 'retval' is never read".
>>> Next are nullptrs (~750). Having glanced at a few of those, I have to
>>> say that some do look pretty real to me (e.g. report-LbUOdn.html ) but
>>> I'm not sure just how different the rules are for the kernel.
>>> Quite a few issues (400-600) are related to garbage value assignment
>>> and propagation. How does that happen? Like this: "unsigned int
>>> uninitialized_var(msecs);" -- so no surprise there.
>>> For the rest, feel free to check out the tarball.
>>>
>>> Goals.
>>> Primary goal for now: integrate checking methods into llvmlinux's build
>>> system.
>>>
>>> Comments, concerns?
>>>
>>> Eduard
>>> _______________________________________________
>>> LLVMLinux mailing list
>>> LLVMLinux at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux
>>
>>
>
>
> _______________________________________________
> LLVMLinux mailing list
> LLVMLinux at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux