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.

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

Reply via email to