Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open-sourcing Facebook Infer: Identify bugs before you ship

code.facebook.com

Post reply on HN
Print view View original

41–50 of 121 posts

Re: Open-sourcing Facebook Infer: Identify bugs before you ship

#41

Post by jasonlotito »

Cthulhu_ wrote: post #16

Gave it a quick trial for iOS... doesn't seem great. It doesn't run at all when giving it a whole project (no response, no CPU usage, not even when you feed it BS arguments), it gives a "Starting Analysis" and nothing else for other (simple) files, it doesn't understand the newish 'nullable' keyword, and it will quit with a fatal error if it can't resolve an import (like UIKit), so pretty unusable on single files. I'…

Tried it on one of my iOS project for an app in the app store, and it worked, highlighting as expected. Possibly setting the wrong arguments?

Re: Open-sourcing Facebook Infer: Identify bugs before you ship

#42

Post by dulma »

suyash wrote: post #30
sadert wrote: post #28

What's the difference between this and the Clang analyzer, which comes with Xcode already? I expected that comparison to be on the front page... http://clang-analyzer.llvm.org/ (obviously it supports Java as well, but I assume Android Studio comes with some sort of static analyzer as well, so same question?) It specifically calls out null pointer exceptions but those... aren't a thing... in Objective-C, messages pass…

Yes Android Studio does come with a static checker called 'Lint' and I'm wondering the same. What are infer's advantages over 'Lint' or even 'findbugs'?

Infer finds deeper infer-procedural bugs sometimes spanning multiple files. Linters, in contrast, typically implement simple syntactic checks that are local within one procedure. But they are valuable and Infer doesn't try to duplicate what they are good at. At Facebook we run both Infer and a collection of Android linters.

Findbugs can be useful too; it is more akin to linters.

Re: Open-sourcing Facebook Infer: Identify bugs before you ship

#43

Post by _shb »

gschrader wrote: post #15

How does this compare to other static code analysis tools like Findbugs, PMD, Checkstyle, etc?

To paint these tools with an overfly broad brush, they linter-like in that they perform shallow intra-procedural analysis to identify common bug patterns (e.g., if (x != null) { y = x.f } z = x.f // possible NPE; x was previously checked for null or foo(String s) { if ("x" == s) // oops, should use .equals() for Java String comparison. }).

By contrast, Infer performs deeper inter-procedural reasoning that can track the flow of values across long chains of procedure calls to identify subtle bugs that are hard to see with the naked eye. Infer doesn't support as many bug patterns as these existing tools do yet, but it can find some deep bugs that these tools will miss.

Re: Open-sourcing Facebook Infer: Identify bugs before you ship

#44

Post by jackpirate »

pcwalton wrote: post #23
tptacek wrote: post #19

Can someone explain-it-like-I'm-a-90s-programmer (ELi90s?) why so much symbolic evaluation stuff gets done in OCaml? What does OCaml do that makes it so well suited for this problem domain? (I know a very little bit about symbolic evaluation and have done a very very little bit of it).

In addition to what the other commenter said, pattern matching is really nice for this kind of thing. Of all of the functional programming languages, OCaml has probably the most sophisticated pattern matching engine around (and we basically copied it into Rust, incidentally), supporting or-patterns, multiple bindings, guards, and so forth. Pattern matching lets you essentially match on the shape of subtrees of arbitr…

In what ways is OCaml's pattern matching superior to Haskell's?

Re: Open-sourcing Facebook Infer: Identify bugs before you ship

#45

Post by theblatte »

aristus wrote: post #17
amirmc wrote: post #3

More OCaml code coming out of FB. Can add this to the list, which includes, Hack, Flow and Pfff [1]. The kinds of bugs it finds are listed at: http://fbinfer.com/docs/infer-bug-types.html It's interesting to see how building tools with languages like OCaml can reduce bugs for teams, without them having to change the language itself. I do wonder what things would be like if such languages we're used directly more wide…

Legend has it there is a small room at FBHQ, containing a quorum of OCaml committers, all of them French for some reason, hacking away at level of abstraction beyond the ken of mortal man.

I'm posting from that very room right now.

Re: Open-sourcing Facebook Infer: Identify bugs before you ship

#46

Post by OxO4 »

dulma wrote: post #36
sadert wrote: post #28

What's the difference between this and the Clang analyzer, which comes with Xcode already? I expected that comparison to be on the front page... http://clang-analyzer.llvm.org/ (obviously it supports Java as well, but I assume Android Studio comes with some sort of static analyzer as well, so same question?) It specifically calls out null pointer exceptions but those... aren't a thing... in Objective-C, messages pass…

On iOS there is the Clang Static analyzer. Infer does some things different, in particular reasoning that spans across multiple files. But CSA checks for more kinds of issues and is also more mature than Infer when it comes to iOS: we send big respect to CSA! Infer has only got started there recently. Really, these tools complement one another and it would even make sense to use both. Indeed, that's what we do inside…

Sorry to hijack your comment but it sounds like you are one of the devs of Infer. I am working on static analysis as part of my PhD and I am going to be an intern at Facebook MPK this summer. Are you located at MPK as well? Any chance we could meet up for some coffee at some point?

Re: Open-sourcing Facebook Infer: Identify bugs before you ship

#48

Post by Locke1689 »

tptacek wrote: post #31
guepe wrote: post #14

The types of issues discovered (they mention null pointer access and resource and memory leaks) is much smaller than what a tool like Coverity will find (I use it). And they analyze C and Java, two languages supported by Coverity, a very mature tool... I am not certain of the proposed value, except it's free to other than Facebook - but not to Facebook, who pays engineers to develop this... Is this some kind of NIH s…

Isn't Coverity expensive?

I would say a Coverity installation at Facebook is probably a "let's talk" level of expensive.

That said, paying a team of expert engineers is also very expensive, not to mention the opportunity cost.

Re: Open-sourcing Facebook Infer: Identify bugs before you ship

#49

Post by pcwalton »

jackpirate wrote: post #44
pcwalton wrote: post #23

Earlier quoted context omitted.

In addition to what the other commenter said, pattern matching is really nice for this kind of thing. Of all of the functional programming languages, OCaml has probably the most sophisticated pattern matching engine around (and we basically copied it into Rust, incidentally), supporting or-patterns, multiple bindings, guards, and so forth. Pattern matching lets you essentially match on the shape of subtrees of arbitr…

In what ways is OCaml's pattern matching superior to Haskell's?

Or patterns.

See http://stackoverflow.com/questions/24700762/or-patterns-in-h...

Re: Open-sourcing Facebook Infer: Identify bugs before you ship

#50

Post by tptacek »

Locke1689 wrote: post #48
tptacek wrote: post #31

Earlier quoted context omitted.

Isn't Coverity expensive?

I would say a Coverity installation at Facebook is probably a "let's talk" level of expensive. That said, paying a team of expert engineers is also very expensive, not to mention the opportunity cost.

Right, and for Facebook internally, whatever the number is, it's a speed bump.

But some reasons not to use Coverity then:

* Doing it in-house gives Facebook near total control over what the system is going to focus on; they can tailor it exactly to their problem set.

* It's a worthwhile open source project, since most values of "expensive" mean "other projects won't ever use it".

* If it gets any traction as an open source project, they can draft off the work other people will put into it.

Post reply on HN