Re: About static analyzers on some various projects

[Ehsan Akhgari]

On 2015-09-28 3:01 AM, Jörg Knobloch wrote:

On 27/09/2015 23:22, Ehsan Akhgari wrote:

Thanks! I submitted fixes for a number of these.


Great. I saw these bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1208905
https://bugzilla.mozilla.org/show_bug.cgi?id=1208904
https://bugzilla.mozilla.org/show_bug.cgi?id=1208903
https://bugzilla.mozilla.org/show_bug.cgi?id=1208902
https://bugzilla.mozilla.org/show_bug.cgi?id=1208901
https://bugzilla.mozilla.org/show_bug.cgi?id=1208900
https://bugzilla.mozilla.org/show_bug.cgi?id=1208899
https://bugzilla.mozilla.org/show_bug.cgi?id=1208897
https://bugzilla.mozilla.org/show_bug.cgi?id=1208885
https://bugzilla.mozilla.org/show_bug.cgi?id=1208884

Do we keep track which issues are still open after your fixes? I haven't
done a cross-check.


No, I haven't fixed all of them.  I am not interested in performing any 
kind of tracking here since I cannot run Viva64 myself.  If you or 
someone else wants to keep track of this work, please do so!



How about this one?
http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsNativeThemeWin.cpp#924


Bug 1209141.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Gregory Szorc]

On Sun, Sep 27, 2015 at 10:54 AM, Ehsan Akhgari 
wrote:

> On 2015-09-25 7:35 PM, Robert O'Callahan wrote:
>
>> On Sat, Sep 26, 2015 at 7:34 AM, Ehsan Akhgari > > wrote:
>>
>> On 2015-09-25 12:01 PM, Justin Dolske wrote:
>>
>> At Mozilla, it seems like previous discussions on this kind of
>> thing
>> (style and warnings come to mind) have dealt with this at a
>> file/directory/module level... Someone fixes up a thing
>> completely, adds
>> it to a whitelist, and then it's a simple pass/fail. Could that
>> work
>> here too?
>>
>>
>> Yes, that is another option for checks that tons of existing code
>> don't pass.
>>
>>
>> That'll help some.
>>
>> The problem of attributing new errors to the correct part of the diff
>> remains, and is quite interesting.
>>
>
> FWIW based on an in-person discussion with gps last week, it seems like
> MozReview's static analysis support is built for cheap analyses that do not
> need to invoke the build system, so C++ analysis will probably not be
> integrated with MozReview (at least not any time soon), so we're going to
> need to rely on try pushes any way.
>
> I'm working on extending our C++ static analysis coverage so I hope to
> make it much more difficult for something to get past the checks on various
> platforms in the future.


We can and should figure out ways for Try pushes with a corresponding
MozReview review to submit results back to MozReview (instead of having to
sift through Treeherder job results). I'm not yet sure if this integration
is performed as part of the job itself or as part of TreeHerder. For now,
we can future proof ourselves by producing machine readable output of all
static analysis results. If the data is produced and readable, we'll figure
out a way to consume and present it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Ehsan Akhgari]

On 2015-09-28 2:10 AM, Philip Chee wrote:

On 28/09/2015 02:29, Jörg Knobloch wrote:

This showed up on the Thunderbird development mailing list:


Hi.
I want to inform you that Thunderbird was checked by PVS-Studio (static
analyzer of C/C++ code). You can find summary of the check here
. There is one false alarm as well as
author's mistake (getenv warning), it will be fixed.
Best regards, Igor Shtukarev.


Click the link and you'll be surprised.
Some (or most) of the errors are actually in M-C code.
I didn't check them all, but here are some beauties:

http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/nsHTMLEditRules.cpp#7392
http://mxr.mozilla.org/mozilla-central/source/extensions/spellcheck/src/mozSpellI18NManager.cpp#31
http://mxr.mozilla.org/mozilla-central/source/xpcom/ds/nsWindowsRegKey.cpp#313
http://mxr.mozilla.org/mozilla-central/source/accessible/windows/sdn/sdnAccessible.cpp#223


If you follow the links to his website (http://www.viva64.com/), there
is a link to his Firefox analysis too[1]. Maybe he doesn't realize that
Firefox and Thunderbird share a lot of platform code?


The Firefox analysis is old, and we fixed some of the stuff it found 
when it came out last year.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Jörg Knobloch]

On 27/09/2015 23:22, Ehsan Akhgari wrote:
Thanks! I submitted fixes for a number of these. 


Great. I saw these bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1208905
https://bugzilla.mozilla.org/show_bug.cgi?id=1208904
https://bugzilla.mozilla.org/show_bug.cgi?id=1208903
https://bugzilla.mozilla.org/show_bug.cgi?id=1208902
https://bugzilla.mozilla.org/show_bug.cgi?id=1208901
https://bugzilla.mozilla.org/show_bug.cgi?id=1208900
https://bugzilla.mozilla.org/show_bug.cgi?id=1208899
https://bugzilla.mozilla.org/show_bug.cgi?id=1208897
https://bugzilla.mozilla.org/show_bug.cgi?id=1208885
https://bugzilla.mozilla.org/show_bug.cgi?id=1208884

Do we keep track which issues are still open after your fixes? I haven't 
done a cross-check.

How about this one?
http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsNativeThemeWin.cpp#924

Jorg K.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Philip Chee]

On 28/09/2015 02:29, Jörg Knobloch wrote:
> This showed up on the Thunderbird development mailing list:
> 
> 
> Hi.
> I want to inform you that Thunderbird was checked by PVS-Studio (static
> analyzer of C/C++ code). You can find summary of the check here
> . There is one false alarm as well as
> author's mistake (getenv warning), it will be fixed.
> Best regards, Igor Shtukarev.
> 
> 
> Click the link and you'll be surprised.
> Some (or most) of the errors are actually in M-C code.
> I didn't check them all, but here are some beauties:
> 
> http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/nsHTMLEditRules.cpp#7392
> http://mxr.mozilla.org/mozilla-central/source/extensions/spellcheck/src/mozSpellI18NManager.cpp#31
> http://mxr.mozilla.org/mozilla-central/source/xpcom/ds/nsWindowsRegKey.cpp#313
> http://mxr.mozilla.org/mozilla-central/source/accessible/windows/sdn/sdnAccessible.cpp#223

If you follow the links to his website (http://www.viva64.com/), there
is a link to his Firefox analysis too[1]. Maybe he doesn't realize that
Firefox and Thunderbird share a lot of platform code?


[1] http://www.viva64.com/en/b/0262/

Phil

-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Ehsan Akhgari]

On 2015-09-25 7:35 PM, Robert O'Callahan wrote:

On Sat, Sep 26, 2015 at 7:34 AM, Ehsan Akhgari > wrote:

On 2015-09-25 12:01 PM, Justin Dolske wrote:

At Mozilla, it seems like previous discussions on this kind of thing
(style and warnings come to mind) have dealt with this at a
file/directory/module level... Someone fixes up a thing
completely, adds
it to a whitelist, and then it's a simple pass/fail. Could that work
here too?


Yes, that is another option for checks that tons of existing code
don't pass.


That'll help some.

The problem of attributing new errors to the correct part of the diff
remains, and is quite interesting.


FWIW based on an in-person discussion with gps last week, it seems like 
MozReview's static analysis support is built for cheap analyses that do 
not need to invoke the build system, so C++ analysis will probably not 
be integrated with MozReview (at least not any time soon), so we're 
going to need to rely on try pushes any way.


I'm working on extending our C++ static analysis coverage so I hope to 
make it much more difficult for something to get past the checks on 
various platforms in the future.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Ehsan Akhgari]

Thanks!  I submitted fixes for a number of these.

On 2015-09-27 2:29 PM, Jörg Knobloch wrote:

This showed up on the Thunderbird development mailing list:


Hi.
I want to inform you that Thunderbird was checked by PVS-Studio (static
analyzer of C/C++ code). You can find summary of the check here
. There is one false alarm as well as
author's mistake (getenv warning), it will be fixed.
Best regards, Igor Shtukarev.


Click the link and you'll be surprised.
Some (or most) of the errors are actually in M-C code.
I didn't check them all, but here are some beauties:

http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/nsHTMLEditRules.cpp#7392

http://mxr.mozilla.org/mozilla-central/source/extensions/spellcheck/src/mozSpellI18NManager.cpp#31

http://mxr.mozilla.org/mozilla-central/source/xpcom/ds/nsWindowsRegKey.cpp#313

http://mxr.mozilla.org/mozilla-central/source/accessible/windows/sdn/sdnAccessible.cpp#223


Jorg K.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[David Rajchenbach-Teller]

That's great work!

Fwiw, my personal use case would be to subscribe to be informed (through
a RSS feed?) if new errors are detected in specific directories or
specific files. Would this be feasible?

Also, any chance we could also get Facebook Flow for JS code?

Plenty of kudos,
 David
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Josh Matthews]

On 2015-09-25 10:06 AM, Robert O'Callahan wrote:

On Sat, Sep 26, 2015 at 1:46 AM, Ehsan Akhgari 
wrote:


Our static analysis builds can be easily triggered from the try server
(although I have been unable to get anyone interested to fix bug 1116518 to
make those builds happen on the try server by default, which makes it all
too easy for people to forget to turn on these builds from their trychooser
syntax) so as soon as the code is pushed to try (perhaps through autoland)
the check failures will be visible as build failures.  I'm not quite sure
what it would take to get those build failures to appear in MozReview but
it should be possible.



The tricky bit is to determine which failures were introduced by the patch,
and just display those, and display them in the context of the patch in
some way that makes sense.

Rob



If the static checkers are not a big resource drain, we could just run 
it on the parent revision as well and diff the output. Alternatively, 
store the results of such runs against our non-try branches somewhere 
where the results are easily accessible, then again fetch and diff.


Cheers,
JOsh
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Justin Dolske]

On 9/25/15 7:06 AM, Robert O'Callahan wrote:


[...]I'm not quite sure
what it would take to get those build failures to appear in MozReview but
it should be possible.



The tricky bit is to determine which failures were introduced by the patch,
and just display those, and display them in the context of the patch in
some way that makes sense.


Yeah, I think this needs a solution to be effective.

*begin thousand yard stare*

In a previous life at Sun, all new code was required to pass lint and 
cstyle checks, and it was strictly enforced. Of course, tons of existing 
code did not pass, and so it became an enormous PITA to diff piles of 
output.


At Mozilla, it seems like previous discussions on this kind of thing 
(style and warnings come to mind) have dealt with this at a 
file/directory/module level... Someone fixes up a thing completely, adds 
it to a whitelist, and then it's a simple pass/fail. Could that work 
here too?


Justin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Ehsan Akhgari]

On Fri, Sep 25, 2015 at 10:06 AM, Robert O'Callahan 
wrote:

> On Sat, Sep 26, 2015 at 1:46 AM, Ehsan Akhgari 
> wrote:
>
> Our static analysis builds can be easily triggered from the try server
>> (although I have been unable to get anyone interested to fix bug 1116518 to
>> make those builds happen on the try server by default, which makes it all
>> too easy for people to forget to turn on these builds from their trychooser
>> syntax) so as soon as the code is pushed to try (perhaps through autoland)
>> the check failures will be visible as build failures.  I'm not quite sure
>> what it would take to get those build failures to appear in MozReview but
>> it should be possible.
>>
>
> The tricky bit is to determine which failures were introduced by the
> patch, and just display those, and display them in the context of the patch
> in some way that makes sense.
>

The way that the existing static analysis bots work, those will simply be
all failures.  :-)

-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Nicholas Nethercote]

On Fri, Sep 25, 2015 at 11:46 PM, Ehsan Akhgari  wrote:
>
> Our static analysis builds can be easily triggered from the try server
> (although I have been unable to get anyone interested to fix bug 1116518 to
> make those builds happen on the try server by default, which makes it all
> too easy for people to forget to turn on these builds from their trychooser
> syntax)

But static analysis does run if you do a |-p all| build. Speaking for
myself, almost every try push I do is |-p all| because I've broken the
tree enough times to have learned my lesson :)

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Robert O'Callahan]

On Sat, Sep 26, 2015 at 7:34 AM, Ehsan Akhgari 
wrote:

> On 2015-09-25 12:01 PM, Justin Dolske wrote:
>
>> At Mozilla, it seems like previous discussions on this kind of thing
>> (style and warnings come to mind) have dealt with this at a
>> file/directory/module level... Someone fixes up a thing completely, adds
>> it to a whitelist, and then it's a simple pass/fail. Could that work
>> here too?
>>
>
> Yes, that is another option for checks that tons of existing code don't
> pass.


That'll help some.

The problem of attributing new errors to the correct part of the diff
remains, and is quite interesting.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Ehsan Akhgari]

On 2015-09-25 5:35 AM, Sylvestre Ledru wrote:

Le 24/09/2015 23:29, Ehsan Akhgari a écrit :

On 2015-09-24 1:41 PM, Sylvestre Ledru wrote:

= Static analyzers =
For now, we are running:
* Coverity, a proprietary tool with a great (but slow) web interface. As
Firefox is Free software, the service is provided for free
but with a restriction in term of number of build. Now, the analysis is
launched once a week on Monday. Supports C, C++ & Java.
A few improvements will be made to silent some of the defects.


Does anybody look at these regularly?

I am looking at the weekly reports. I am reporting the issue I can confirm.
However, to be honest, I am not technically able to analyze every one of them.
I am also tagging false positive to keep a clean database.

FYI, at some point, we might have someone to help on this full time.


That would be nice, although I'm not sure if we need one full time 
position just for this purpose!  But having someone who tracks these 
issues is definitely good.



I would be interested to know if they produce high quality results these days.  
My past experience with Coverity has been that it's full of false positivies.

Several answers:
* I think the results are still pretty much the same
* false positives can be silent. This is a work to be done either in our code 
(you reviewed some of my patches for this in the past)
or in coverity
* some checkers have a small false positives ratio, some other, an higher.


Yeah.  My point was that if we find out that for example codechecker 
gives us higher quality results, we should focus on that more.



* scan-build (aka clang-analyzer), a static analyzer integrated into
Clang. This tool is executed every day. Support C & C++.
The main issue with scan-build is that here is no history management and
it is not really possible to ignore false positive.
Ericsson started to work on a new (Python) tool based on clang-analyzer
called Code Checker - https://github.com/Ericsson/codechecker
to address that.


FWIW I am planning to stand this up for us at some point (hopefully soon.)


Could you share some details? I am on the process of deploying code checker.


I haven't started any actual work yet, that was on my list.  If you're 
in the process of doing this, I will eagerly wait.  :-)  Is there a bug 
# or something else that I can use to keep track of this work?  (And 
thanks for making it happen!)



== Infer ==

Firefox (just C code):
https://people.mozilla.org/~sledru/reports/firefox-infer/bugs.txt

Fennec (Java code):
https://people.mozilla.org/~sledru/reports/fennec-infer/bugs.txt


Neat!  I did not know about this one.  Has anyone looked at the results?

This bug https://bugzilla.mozilla.org/show_bug.cgi?id=1175203 has been reported
but no activity.


Those are Java issues which should probably be discussed more with the 
Android team.  After having a cursory look over a few of the C++ ones, 
most looked like false positives (the leak in 
xpcom/tests/TestJemalloc.cpp was real but that's a test...)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Sylvestre Ledru]

Le 24/09/2015 23:29, Ehsan Akhgari a écrit :
> On 2015-09-24 1:41 PM, Sylvestre Ledru wrote:
>> = Static analyzers =
>> For now, we are running:
>> * Coverity, a proprietary tool with a great (but slow) web interface. As
>> Firefox is Free software, the service is provided for free
>> but with a restriction in term of number of build. Now, the analysis is
>> launched once a week on Monday. Supports C, C++ & Java.
>> A few improvements will be made to silent some of the defects.
>
> Does anybody look at these regularly?  
I am looking at the weekly reports. I am reporting the issue I can confirm.
However, to be honest, I am not technically able to analyze every one of them.
I am also tagging false positive to keep a clean database.

FYI, at some point, we might have someone to help on this full time.

> I would be interested to know if they produce high quality results these 
> days.  My past experience with Coverity has been that it's full of false 
> positivies.
Several answers:
* I think the results are still pretty much the same
* false positives can be silent. This is a work to be done either in our code 
(you reviewed some of my patches for this in the past)
or in coverity
* some checkers have a small false positives ratio, some other, an higher.
>
>> * scan-build (aka clang-analyzer), a static analyzer integrated into
>> Clang. This tool is executed every day. Support C & C++.
>> The main issue with scan-build is that here is no history management and
>> it is not really possible to ignore false positive.
>> Ericsson started to work on a new (Python) tool based on clang-analyzer
>> called Code Checker - https://github.com/Ericsson/codechecker
>> to address that.
>
> FWIW I am planning to stand this up for us at some point (hopefully soon.)
>
Could you share some details? I am on the process of deploying code checker.
>> == Infer ==
>>
>> Firefox (just C code):
>> https://people.mozilla.org/~sledru/reports/firefox-infer/bugs.txt
>>
>> Fennec (Java code):
>> https://people.mozilla.org/~sledru/reports/fennec-infer/bugs.txt
>
> Neat!  I did not know about this one.  Has anyone looked at the results?
This bug https://bugzilla.mozilla.org/show_bug.cgi?id=1175203 has been reported
but no activity.

Sylvestre
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Robert O'Callahan]

On Sat, Sep 26, 2015 at 1:46 AM, Ehsan Akhgari 
wrote:

> Our static analysis builds can be easily triggered from the try server
> (although I have been unable to get anyone interested to fix bug 1116518 to
> make those builds happen on the try server by default, which makes it all
> too easy for people to forget to turn on these builds from their trychooser
> syntax) so as soon as the code is pushed to try (perhaps through autoland)
> the check failures will be visible as build failures.  I'm not quite sure
> what it would take to get those build failures to appear in MozReview but
> it should be possible.
>

The tricky bit is to determine which failures were introduced by the patch,
and just display those, and display them in the context of the patch in
some way that makes sense.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Gregory Szorc]

On Fri, Sep 25, 2015 at 12:19 AM, Robert O'Callahan 
wrote:

> On Fri, Sep 25, 2015 at 5:41 AM, Sylvestre Ledru 
> wrote:
>
> > Any questions, comments?
> >
>
> This whitepaper on Infer is an interesting read:
>
> https://fbcdn-dragon-a.akamaihd.net/hphotos-ak-xap1/t39.2365-6/10935986_985284008163608_74391_n/Moving_Fast_with_Software_Verification.pdf
> (misleading title though).
> (Apart from the comments about the tool, I like the observation that mobile
> app development is a problem for Facebook compared to Web because they have
> to support old versions of their app.)
> One of the key things in that paper, which I've claimed for a while, is
> that the real value of static analysis tools for developers like us is to
> apply them at code review time. That's when developers are motivated to
> clean up, explain, and fix their code, and when it's cheapest to do so. So
> I'm looking forward to having support in Mozreview for automated drive-by
> reviews, and then it would be really valuable to adapt these tools to do
> such reviews --- at least as valuable as running them over the whole
> codebase.


We are actively working to integrate automatic review bots into MozReview.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

About static analyzers on some various projects

[Sylvestre Ledru]

Hello,

An update on the various static analyzers that we are running on the
Firefox, Fennec, NSS, NSPR and Thunderbird code.

Warning: these tools are not Silver bullets. Due to their nature, they
are going to generate false positives.
However, they do find some important and critical issues early in the cycle.

= Static analyzers =
For now, we are running:
* Coverity, a proprietary tool with a great (but slow) web interface. As
Firefox is Free software, the service is provided for free
but with a restriction in term of number of build. Now, the analysis is
launched once a week on Monday. Supports C, C++ & Java.
A few improvements will be made to silent some of the defects.

* scan-build (aka clang-analyzer), a static analyzer integrated into
Clang. This tool is executed every day. Support C & C++.
The main issue with scan-build is that here is no history management and
it is not really possible to ignore false positive.
Ericsson started to work on a new (Python) tool based on clang-analyzer
called Code Checker - https://github.com/Ericsson/codechecker
to address that.

* infer, the brand new Ocaml-based and Clang static analyzer developed
by Facebook. Run every day.
For now, supports C, Java and Objective-C. Mostly developed for their
needs for mobile apps.
I have been discussing with the developers on this.

= About the reports =

== Coverity ==
To see the Coverity reports, an account is needed and a Coverity admins
(Dan Veditz or I) will have to approve the application.
Only @mozilla.{com,org} email addresses will be accepted.
https://scan.coverity.com/projects/firefox
https://scan.coverity.com/projects/firefox-mobile - I don't trust the
coverity results for Fennec yet.I think many Java files have not been
processed
I asked help to the editor of this software and on their forum (
https://communities.coverity.com/thread/3442 ) but no news.


== Scan-builds ==

Scan-build reports are limited to Mozilla employees. Persona
authentication is used login.
Firefox:
https://people.mozilla.org/~sledru/reports/fx-scan-build/

Thunderbird:
https://people.mozilla.org/~sledru/reports/tb-scan-build/

NSS:
https://people.mozilla.org/~sledru/reports/nss-scan-build/

NSPR:
https://people.mozilla.org/~sledru/reports/nspr-scan-build/


== Infer ==

Firefox (just C code):
https://people.mozilla.org/~sledru/reports/firefox-infer/bugs.txt

Fennec (Java code):
https://people.mozilla.org/~sledru/reports/fennec-infer/bugs.txt


= Future =
As a goal, I would like to see that integrated in our workflows.


Any questions, comments?


Technically, the jobs are managed by a Jenkins instance:
http://relman-ci.mozilla.org/ - sources can be found here:
https://github.com/sylvestre/relman-ci

Sylvestre


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Robert O'Callahan]

Why not make scan-builds and infer results public? Those are public tools
so we should assume black-hats already have the resutls.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Andrew McCreight]

On Thu, Sep 24, 2015 at 4:23 PM, Nicholas Nethercote  wrote:

> On Thu, Sep 24, 2015 at 2:29 PM, Ehsan Akhgari 
> wrote:
> > On 2015-09-24 1:41 PM, Sylvestre Ledru wrote:
> >>
> >> * Coverity, a proprietary tool with a great (but slow) web interface.
> >
> > Does anybody look at these regularly?  I would be interested to know if
> they
> > produce high quality results these days.  My past experience with
> Coverity
> > has been that it's full of false positivies.
>
> Eric Rahm looks at them regularly. He's on PTO until next week. From
> what he's told me the false positive rate is quite high, and the true
> positives are mostly small things like leaks on error paths, but
> occasionally it finds something significant. He's been looking at them
> for some time which suggests he thinks it's worth the effort.
>

I've described our Coverity results as a "good first bug generator". There
are a ton of little local things to fix.

One interesting analysis it has that I don't think we've taken advantage of
is that it reports when most, but not all, calls to a function have their
return value checked. In addition to indicating possible places where we
might need to do more checks, it also hints at functions that maybe should
have MOZ_WARN_UNUSED_RESULT added.


ps. "infer" uses separation logic, which happens to be a topic I know a bit
about, if anybody wants to know more about it.

Andrew


>
> Nick
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Nicholas Nethercote]

On Thu, Sep 24, 2015 at 2:29 PM, Ehsan Akhgari  wrote:
> On 2015-09-24 1:41 PM, Sylvestre Ledru wrote:
>>
>> * Coverity, a proprietary tool with a great (but slow) web interface.
>
> Does anybody look at these regularly?  I would be interested to know if they
> produce high quality results these days.  My past experience with Coverity
> has been that it's full of false positivies.

Eric Rahm looks at them regularly. He's on PTO until next week. From
what he's told me the false positive rate is quite high, and the true
positives are mostly small things like leaks on error paths, but
occasionally it finds something significant. He's been looking at them
for some time which suggests he thinks it's worth the effort.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Ehsan Akhgari]

On 2015-09-24 1:41 PM, Sylvestre Ledru wrote:

= Static analyzers =
For now, we are running:
* Coverity, a proprietary tool with a great (but slow) web interface. As
Firefox is Free software, the service is provided for free
but with a restriction in term of number of build. Now, the analysis is
launched once a week on Monday. Supports C, C++ & Java.
A few improvements will be made to silent some of the defects.


Does anybody look at these regularly?  I would be interested to know if 
they produce high quality results these days.  My past experience with 
Coverity has been that it's full of false positivies.



* scan-build (aka clang-analyzer), a static analyzer integrated into
Clang. This tool is executed every day. Support C & C++.
The main issue with scan-build is that here is no history management and
it is not really possible to ignore false positive.
Ericsson started to work on a new (Python) tool based on clang-analyzer
called Code Checker - https://github.com/Ericsson/codechecker
to address that.


FWIW I am planning to stand this up for us at some point (hopefully soon.)


== Infer ==

Firefox (just C code):
https://people.mozilla.org/~sledru/reports/firefox-infer/bugs.txt

Fennec (Java code):
https://people.mozilla.org/~sledru/reports/fennec-infer/bugs.txt


Neat!  I did not know about this one.  Has anyone looked at the results?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Jean-Yves Avenard]

On Friday, September 25, 2015 at 7:29:19 AM UTC+10, Ehsan Akhgari wrote:
> On 2015-09-24 1:41 PM, Sylvestre Ledru wrote:
> > = Static analyzers =
> > For now, we are running:
> > * Coverity, a proprietary tool with a great (but slow) web interface. As
> > Firefox is Free software, the service is provided for free
> > but with a restriction in term of number of build. Now, the analysis is
> > launched once a week on Monday. Supports C, C++ & Java.
> > A few improvements will be made to silent some of the defects.
> 
> Does anybody look at these regularly?  I would be interested to know if 
> they produce high quality results these days.  My past experience with 
> Coverity has been that it's full of false positivies.
> 

I regularly looked at coverity logged bug in our bugzilla, and fix the ones 
related to media (not many)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Robert O'Callahan]

On Fri, Sep 25, 2015 at 5:41 AM, Sylvestre Ledru 
wrote:

> Any questions, comments?
>

This whitepaper on Infer is an interesting read:
https://fbcdn-dragon-a.akamaihd.net/hphotos-ak-xap1/t39.2365-6/10935986_985284008163608_74391_n/Moving_Fast_with_Software_Verification.pdf
(misleading title though).
(Apart from the comments about the tool, I like the observation that mobile
app development is a problem for Facebook compared to Web because they have
to support old versions of their app.)
One of the key things in that paper, which I've claimed for a while, is
that the real value of static analysis tools for developers like us is to
apply them at code review time. That's when developers are motivated to
clean up, explain, and fix their code, and when it's cheapest to do so. So
I'm looking forward to having support in Mozreview for automated drive-by
reviews, and then it would be really valuable to adapt these tools to do
such reviews --- at least as valuable as running them over the whole
codebase.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform