On Sat, Feb 7, 2015 at 3:32 PM, Cyrille Artho <[email protected]> wrote: > Hi all, > It's a good idea to look at these reports from time to time. > > Note that usually some of the defects reported by static analysis are "false > positives"; they may actually work as intended in the code due to the way a > particular part of code behaves at run-time. > Coverity has some facilities to deal with false positives.
For instance, it is possible to classify an identified issue as "false positive" or "intentional", meaning that Coverity shall ignore it in future code scans. But more usefully we can specify a Modeling File: "Static code analysis has some limitations in its ability to understand certain dynamic operations. This limitation may result in falsely detecting defects. Since most false-positive defects are caused by few functions in your code base, Coverity allows you to tell the analysis engine to treat these functions differently. This is called a Modeling File. By providing a modeling file, most projects reduce their false-positive rate to the ballpark of 10%." Cheers, Liviu > Sometimes it's possible to rewrite the code slightly to eliminate false > positives; in many cases, slightly changing the code may also make it easier > for humans to understand, not just for Coverity. > > As we've found various memory corruption bugs only by testing, it's > definitely a good idea to ensure that the warnings are fixed over time. > Hopefully this will make some of the more elusive bugs we've had, a thing of > the past. > > > > Liviu Andronic wrote: >> >> Dear all, >> Following on this very old proposal, I went ahead and submitted the >> LyX code for static analysis to Coverity: >> https://scan.coverity.com/projects/4164 >> >> Coverity has uncovered ~250 implementation defects in the LyX code >> base, with 10 or so of high severity (memory corruption, resource >> leaks, etc.) To view the defects, you need to connect with your Github >> account (or create one with Coverity) and request 'Add me to project' >> (which I shall then approve). Coverity provides overall metrics like >> defect density (LyX scores a respectable 0.53), but also classifies >> uncovered bugs by type and severity, and provides a nice UI trying to >> explain to the devels the specifics of the bug and how to address it >> (e.g. where it happens, why it's an issue, etc.) >> >> This tool is being used by heavy-hitters like LibreOffice, Linux >> Kernel, Firefox or Python to improve the robustness of their code >> base. I suspect that Coverity could prove invaluable when trying to >> hunt down frustrating implementation issues like >> http://www.lyx.org/trac/ticket/8854 or >> http://www.lyx.org/trac/ticket/9049 . >> >> In any case the identified bugs are now ready for inspection by the >> devels, so feel free to drop by! >> >> Regards, >> Liviu >> >> >> On Wed, Feb 24, 2010 at 6:52 PM, John McCabe-Dansted <[email protected]> >> wrote: >>> >>> I found the errors reported by cppcheck much easier to fix than bug >>> reports (e.g. generated by my keytest). For example: >>> [./development/lyxserver/server_monitor.c:173]: (error) Memory >>> leak: pipename >>> This had the obvious solution of adding free(pipename) to line 173. >>> Convincing myself that this fix was correct wasn't quite so trivial, >>> but still much easier than tracing down the cause of a traditional bug >>> report. >>> >>> Unfortunately the cppcheck didn't seem very powerful and only found >>> bugs in code that was virtually unused. >>> >>> My understanding is that Coverity is not only a much more powerful >>> check, but also focuses on making their bug reports easy to understand >>> and free of false-positives [1]. As such it seems that fixing many of >>> the bugs reported by Coverity would be trivial, and may even save time >>> as fixing dangerous code may close some of the hard to track down bugs >>> sitting in trac. >>> >>> If we were to request that Coverity scan LyX would anyone either be >>> interested in either looking through the bugs, or having someone else >>> such as myself look through the bug reports? I understand that those >>> who wish to see the bug reports have to agree to a click through >>> license agreeing that if you produce a competing product to Coverity >>> you won't use any "IP" you learnt about Coverity from looking their >>> bug reports. >>> >>> -- >>> John C. McCabe-Dansted >>> [1] >>> http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext >> >> >> >> > > -- > Regards, > Cyrille Artho - http://artho.com/ > Those who will not reason, are bigots, those who cannot, > are fools, and those who dare not, are slaves. > -- George Gordon Noel Byron -- Do you think you know what math is? http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02 Or what it means to be intelligent? http://www.ideasroadshow.com/issues/john-duncan-2013-08-30 Think again: http://www.ideasroadshow.com/library
