[cfe-dev] [analyzer][GSoC] Problem Statement: Improving BugReporter with static backward program slicing

[Artem Dergachev via cfe-dev]

 > Umm, what do you mean under "data"? Like, proving how the examples I 
showed would be solved by this technique?

I roughly refer-ahead-to the output of step iv. - it should do the 
trick. See if we've already solved the problem at step iii. If not, take 
a few real-world reports that are still bad, try to understand what's 
wrong with them. Eg., are we not stuffing enough slicing criteria into 
them? Or is a more sophisticated slicing algorithm necessary to discover 
some of the dependencies? Or are we instead discovering too many 
dependencies? Or is it a completely unrelated bug that's suddenly 
causing havoc? Rinse and repeat until most of our reports look great :)

On 4/4/19 2:39 PM, Kristóf Umann wrote:
> This. Is. Amazing. Thank you so much for taking the time to assemble 
> this mail! I agree with everything stated above -- I think I'm as 
> ready as I'll ever be to put together a nice looking proposal.
>
> On Thu, 4 Apr 2019 at 22:22, Artem Dergachev <noqnoqneo at gmail.com 
> <mailto:noqnoqneo at gmail.com>> wrote:
>
>     I kinda gathered some understanding of the problem and the
>     solution and trying to come up with some sort of a plan, and for
>     that purpose i'm trying to step back from "we should totally do
>     this cool technique" towards a more "adult", "boring" point of
>     view that consists in asking, "what *do* we need to do?".
>
>     For now i'm seeing that the work on this problem can be decomposed
>     into three chunks:
>
>     (1) Collect slicing criteria from various sources,
>     (2) Perform slicing to discover data and control dependencies,
>     (3) Use information about dependencies to improve the bug report.
>
>     Chunk (3) sounds straightforward: we just enable or disable path
>     pieces based on information we already have. I don't fully
>     understand how it'll go, but i don't see any unknowns here.
>
>     Chunk (1) sounds like a large amount of routine, repetitive work:
>     convert sources of slicing criteria, such as checkers, to the new
>     system one-by-one. There is certain amount of known unknowns here:
>     some sources may be tricky to take advantage of (eg.,
>     liveness-related sources), some may put stress on the checkers.
>
>     Chunk (2) is the research-intensive part: it has an easy 80%
>     solution (AST matching based detection that has already been
>     implemented and proved useful for one of the checkers) and an idea
>     to improve upon it by implementing a more sophisticated analysis.
>
>     Because chunk (2) is research-intensive, we need experimental data
>     that we currently don't have. In order to avoid spending a lot of
>     time on something that isn't going to work, we should try to
>     gather that data as soon as possible in our plan.
>
>
> Umm, what do you mean under "data"? Like, proving how the examples I 
> showed would be solved by this technique?
>
>
>     Because chunk (1) is repetitive, we don't need to implement it
>     completely; we can pick one or two sources and get them right.
>
>     Therefore here's the plan that emerges:
>     i. Pick one or two slicing criteria sources and implement them.
>     ii. Implement a simple AST-based algorithm for discovering
>     dependencies.
>     iii. Apply the information produced by that algorithm to the bug
>     report.
>     iv. Run the updated analyzer on real-world codebases and see what
>     problems remain.
>     v. Implement solutions to these problems.
>
>     Solutions on step v. may or may not be about coding a more
>     sophisticated slicing algorithm. They might as well be
>     improvements in chunk (1), i.e. discovering more slicing criteria,
>     or they may be about a "horizontal" improvement in the existing
>     primitive algorithm (eg., cover more forms of control flow or
>     different variants of data dependencies, which should have been a
>     separate chunk).
>
>     That's roughly how i imagine it.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190404/bede16e4/attachment.html>