<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
My primary question is, how do you plan to use the data that you
obtain via your analysis?<br>
<br>
Like, do you plan to backtrack the value of all relevant variables
and/or expressions in the final bug report that were also
encountered along the bug path? If yes, then is it possible that the
slicing criterion gets updated in the process and you'll have to
re-run the CFG-based analysis to take it into account?<br>
<br>
> What would also be really great is to assist this traversal
with the information the analyzer already has, essentially only
inspecting basic blocks the analyzer actually visits.<br>
<br>
You mean visits on the current bug path or visits on the equivalence
class of bugs or visits in general during analysis?<br>
<br>
Regardless, for many problems ideally we should traverse basic
blocks that the analyzer *didn't* visit (eg., if the function didn't
initialize the variable on the current path, we're interested in
parts of the code in which it *did* initialize the variable, even
though we didn't necessarily have time to visit them).<br>
<br>
It actually sounds as if all problems that we're trying to solve
here can be classified into "must-have-happened" problems (eg.,
"variable must-have been declared without initialization", "variable
must-have been set to nullptr", "memory must-have been allocated")
and "should-not-have-happened" problems (eg., "variable
should-not-have been initialized", "null value should-not-have been
overwritten", "pointer should-not-have escaped").<br>
<br>
For must-have-happened problems, i'm recently under an impression
that we should suppress the bug report entirely when we fail to
solve them (i.e., if fail to explain to the user where exactly does
this happen, then the report is impossible to understand anyway).
This is currently a very big problem for our null dereference
checker on some codebases, especially because it uses this tracking
for suppressions as well (aka inlined defensive checks), so when it
fails to track the variable it's likely a legit false positive as
well, not simply a hard-to-understand report.<br>
<br>
For should-not-have-happened problems i'm much more confused. We're
talking about looking for places where it *could* have happened and
then trying to explain to the user why none of them have actually
happened. I'm not sure what are the consequences of failing to
explain to the user why didn't a particular piece of code do
something, because i've no idea how do users intuitively figure out
which code *could* have done these things and which clearly
couldn't.<br>
<br>
<br>
<div class="moz-cite-prefix">On 5/22/19 4:11 PM, Kristóf Umann
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGcXOD4-MMg=XQLCCqv6ANJWYCp4YMzwxNGDkDvpfGTjgqXKsQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr"><span
id="gmail-docs-internal-guid-3c74b999-7fff-e99a-77f6-4bd5385fb78f">
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Hi!</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">I'd like to share some thoughts about my GSoC project, "Enhancing bug reporting with static backward program slicing"[1].</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">My proposal is very specific about </span><span style="font-family:Arial;background-color:transparent;font-style:italic;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">what</span><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> I'm aiming to improve on, but vague on the </span><span style="font-family:Arial;background-color:transparent;font-style:italic;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">how</span><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> part of it. This mail aims to add clarify some of this.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Program slicing is essentially a technique of discovering data and control dependencies to the slicing criterion, which is a (statement, {set of variables}) pair. Fortunately, tools for control dependencies, namely, dominator set calculations are already implemented, but seems to be unstable with clang's CFG. It would be a great tool if I were able to fix it.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">While my proposal states that I plan to implement an AST-based solution, I'm actually not sure that this is the optimal approach. We could instead inspect CFG blocks in a backwards manner (coupled with the analyzer's call stack), and gather relevant variable in the meanwhile.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">What would also be really great is to assist this traversal with the information the analyzer already has, essentially only inspecting basic blocks the analyzer actually visits.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Here’s my idea for an algorithm (from the point of the slicing criterion already being constructed):</span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">
</span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"><a href="https://docs.google.com/document/d/1Lx867o3meyQsj0WKOSWMdosSBdw2MUq1aIxyPJM6iLU/edit?usp=sharing" moz-do-not-send="true">https://docs.google.com/document/d/1Lx867o3meyQsj0WKOSWMdosSBdw2MUq1aIxyPJM6iLU/edit?usp=sharing</a>
</span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><br>
</p>
<p
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt">Please
note that this is a veeery rough sketch, I didn't think
about every edge case that exists, but I think it's an
okay start.</p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><br>
</p>
</span><span
id="gmail-docs-internal-guid-5954bf5e-7fff-362e-5b73-2faf8cd77d3f"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">[1] <a href="https://docs.google.com/document/d/1ci1BCAKojPlqIxIw1J_K2dnATA3z01PuwR_vHJS55TI/edit" moz-do-not-send="true">https://docs.google.com/document/d/1ci1BCAKojPlqIxIw1J_K2dnATA3z01PuwR_vHJS55TI/edit</a></span></span> <br
class="gmail-Apple-interchange-newline">
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>