Re: Yet more static analysis: Use Coverity?

[Liviu Andronic]

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 gma...@gmail.com 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



-- 
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

Re: Source Tarballs for 2.1.3

[Jean-Pierre Chrétien]

Richard Heck rgheck at lyx.org writes:

 
 
 Source tarballs for 2.1.3 can be found here:
  ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.3/
 Please prepare binaries by Monday. I'd like to do the release on Tuesday.

Compiles and runs fine on Debian Wheezy/TexLive 2014 :

Configuration
  Host type:x86_64-unknown-linux-gnu
  Special build flags:  build=release use-hunspell
  C++ Compiler: g++ (4.7)
  C++ Compiler LyX flags:
  C++ Compiler flags:-O2
  Linker flags: 
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.8.2
  Packaging:posix
  LyX binary dir:   /usr/local/bin
  LyX files dir:/usr/local/share/lyx-2.1.3 

I seldom read the splash file, but I see a reference to 

ViewView-View [PDF (pdflatex)]

which is no more true, it should read 

Document-View [PDF (pdflatex)]

-- 
Jean-Pierre

Re: Source Tarballs for 2.1.3

[Jean-Pierre Chrétien]

Richard Heck  lyx.org> writes:

> 
> 
> Source tarballs for 2.1.3 can be found here:
>  ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.3/
> Please prepare binaries by Monday. I'd like to do the release on Tuesday.

Compiles and runs fine on Debian Wheezy/TexLive 2014 :

Configuration
  Host type:x86_64-unknown-linux-gnu
  Special build flags:  build=release use-hunspell
  C++ Compiler: g++ (4.7)
  C++ Compiler LyX flags:
  C++ Compiler flags:-O2
  Linker flags: 
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.8.2
  Packaging:posix
  LyX binary dir:   /usr/local/bin
  LyX files dir:/usr/local/share/lyx-2.1.3> 

I seldom read the splash file, but I see a reference to 

View>View->View [PDF (pdflatex)]

which is no more true, it should read 

Document->View [PDF (pdflatex)]

-- 
Jean-Pierre

Re: Yet more static analysis: Use Coverity?

[Liviu Andronic]

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  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



-- 
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