<div dir="ltr">Hmm, I think about the opposite. A language that anyone could improve and easy-to-read in a tree structure versus an unknown language (in my point of view) of a raw graph written for the computer.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 5, 2019 at 9:37 PM Artem Dergachev <<a href="mailto:noqnoqneo@gmail.com">noqnoqneo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
Mmm, interesting. I definitely wouldn't mind allocating a week for
that :)<br>
<br>
You might still want to do this in dot files rather than in svg
files, they are a bit more structured.<br>
<br>
<div class="gmail-m_-3580220180502166634moz-cite-prefix">On 4/5/19 6:29 AM, Csaba Dabis wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Hey!
<div><br>
</div>
<div>The ExplodedGraph modification is not that difficult. It
would be really cool to get rid of the entire .SVN file and
convert it to pure .HTML, and yes, it would take months. My
solution is more simple and could be done within a week.</div>
<div><br>
</div>
<div>Here is the task copied:</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It could modify the full
graph to only show differences between states and it would
recolour the current representation for better readability.</blockquote>
<div><br>
</div>
<div>Here is the skeleton of the internal representation of
the .SVG:</div>
<div><font size="1" face="monospace, monospace"><svg></font></div>
<div><font size="1" face="monospace, monospace"> <g
id="node1"></g><br>
</font></div>
<div><font size="1" face="monospace, monospace"> <g
id="node2"></g><br>
<g id="edge1"></g></font></div>
<div><font size="1" face="monospace, monospace"> <g
id="node3"></g></font></div>
<div><font size="1" face="monospace, monospace"> <g
id="edge2"></g><br>
</font></div>
<div><font size="1" face="monospace, monospace"> ...</font></div>
<div><font size="1" face="monospace, monospace"> <g
id="node667"></g></font></div>
<div><font size="1" face="monospace, monospace"> <g
id="edge666"></g><br>
</svg></font></div>
<div><br>
</div>
<div>If `g` is a node, it looks like this:</div>
<font size="1" face="monospace, monospace"><g><br>
<text>Block Entrance: B3</text><br>
<text>PreStmtPurgeDeadSymbols</text><br>
...<br>
<text>reg_$0<const class
clang::ento::MemRegion * this> : { [1,
18446744073709551615] }</text><br>
</g></font>
<div><br>
</div>
<div>-------------</div>
<div><br>
</div>
<div>First idea explained:</div>
<div>The idea is traversing backwards on this tree and check
whether two `texts` are equal in the current and the parent
node, if so tag the `text` of the child node being
duplication. Put a floating checkbox on the top-left corner
and if you click on that it hides the tagged `texts`, second
click should show every entry.</div>
<div><br>
</div>
<div>Second idea explained:</div>
<div>The most common interesting string is `reg_$` and
possibly `derived_$, extent_$, meta_$`, where the `_$`
suffix is not enough eye-catching. I tried to indent them by
obtaining the complexity of the symbolic value and apply
that much space, but it did not work, so make it colourful
could make it better. Both would be the best. Other
important string would be determined on the fly.</div>
<div><br>
</div>
<div>Thanks you for your comments,</div>
<div>Csaba.</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Apr 5, 2019 at 4:15 AM
Artem Dergachev <<a href="mailto:noqnoqneo@gmail.com" target="_blank">noqnoqneo@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"> +actual Ravi as he prefers this
address. Ravi is this dude - <a class="gmail-m_-3580220180502166634gmail-m_6363490170421371912gmail-m_3476356195973442476moz-txt-link-freetext" href="https://github.com/ravikandhadai" target="_blank">https://github.com/ravikandhadai</a>
- he's from the Swift universe and he has a solid academic
background in static analysis (unlike me ^_^") and every
time i tell him we have a checker for this bug, he gets more
and more excited :p<br>
<br>
On 4/4/19 2:26 PM, Csaba Dabis wrote:<br>
<blockquote type="cite">
<div dir="ltr">Hey Clang developers!
<div><br>
</div>
<div>I would like to participate in Google Summer of
Code this year. I am in my fourth semester BSc student
of Computer Science at Eotvos Lorand University,
Hungary. I have started to learn C++ parallel with
Clang a year and a half ago. Also that was the first
time using Linux, Git, VIM…. I love automation so this
engine and tools based on Clang like scan-build,
CodeChecker, CodeCompass.<br>
<br>
I have picked the following project: <a href="http://llvm.org/OpenProjects.html#analyze-llvm" target="_blank">http://llvm.org/OpenProjects.html#analyze-llvm</a></div>
<div>Here is the copy of the problems and their
solutions from my near-finished proposal:</div>
<div><br>
</div>
<font size="4">Goals</font><br>
Eliminate 90% of the false positive findings in LLVM by
teaching C++ to the Static Analyzer. Improve the
existing debugging facilities so it would be easier to
investigate errors. Report and fix the easy-to-fix true
positives in LLVM. Report the difficult-to-fix true
positives in LLVM so other developers with better
experience in that certain area could solve those. Swift
is another heavy project as an example to see how an
LLVM-related project reports are changing. Measure the
quality of the changes in Swift where no direct false
positive elimination happen. With these improvements let
the LLVM and related project contributors use the Static
Analyzer sub-project without any overhead in a
continuous integration workflow.</div>
</blockquote>
<br>
*approves the goals*<br>
<br>
<blockquote type="cite">
<div dir="ltr"><font size="4">Overview of the debugging
facilities</font><br>
The Clang Static Analyzer builds the exploded graph
which consists of program states as nodes. During the
symbolic execution each node represents everything what
we know about the program at a certain location.<br>
<br>
ExplodedGraph: We could investigate the graph with
graphviz as an .SVN file and using Google Chrome. The
graph can be so enormous so that Chrome crashes or even
cannot load it. If you are able to load it, there is too
much information and it is very difficult to use.</div>
</blockquote>
<br>
I mean, our exploded graph dumps are horrible, but i've been
a happy user of them for like 5 years. Pretty much every
single bugfix that i made so far involved an investigation
via exploded graph dumps. And on top of that, i'm not seeing
much information that can be removed from them. Yes, viewers
are choking immediately, browsers through svg conversion are
doing better, especially chrome that seems to have the most
tolerant svg library. But whenever there isn't way to view
an exploded graph, it becomes 5x times harder to debug
anything.<br>
<br>
One of the more personal reasons why i've been rooting for
this project is that i wanted to popularize this systematic
debugging workflow of narrowing down the bug to the Static
Analyzer function in which it's happening that consists
binary-searching the exploded graph dump for invalid values
and bindings. I guess i should actually document it some
day, like, you know, *for once*, 'cause <a class="gmail-m_-3580220180502166634gmail-m_6363490170421371912gmail-m_3476356195973442476moz-txt-link-freetext" href="http://clang-analyzer.llvm.org/checker_dev_manual.html#visualizing" target="_blank">http://clang-analyzer.llvm.org/checker_dev_manual.html#visualizing</a>
is clearly insufficient.<br>
<br>
<blockquote type="cite">
<div dir="ltr">Alternatively you could use LLDB debugger
but because of the such a complex background it is more
difficult to gather information which function causes
the false positive.<br>
<br>
Debug checkers: debug.DumpCalls checker truly writes out
every function call, which is too much and too difficult
to use. Expression inspection checks[1] are useful for
get a feeling what could go wrong by writing out a
certain program state, but it cannot be used to compare
states due to the graph structure.<br>
<br>
<font size="4">Proposed solutions for the debugging
facilities</font><br>
ExplodedGraph: Create an .HTML frontend for the .SVG
graph representation. It could modify the full graph to
only show differences between states and it would
recolour the current representation for better
readability.<br>
</div>
</blockquote>
<br>
It'd be awesome to pull this off, but i suspect this
undertaking alone might take a few months of your time. I
think you should keep your eyes open for potential smaller
improvements but generally try to familiarize yourself with
existing tools before building up long-term plans in this
direction.<br>
<br>
<blockquote type="cite">
<div dir="ltr">Debug checkers: Create an option for
debug.DumpCalls checker to show only a certain variable
and if its value is unknown at the location of an error,
point out when it became unknown.<br>
<br>
<font size="4">Overview of the false positives</font><br>
My playground was the LLVM 8.0.0 bug-free release (20
March 2019). With the basic scan-build command 828 bug
reports found. Because of our precise review system they
are most likely false positive findings, where the half
is ‘Memory leak’ (229) and ‘Called C++ object pointer is
null’ (217) errors:
<div>- ‘Memory leak’: Half of the reports (118/229)
appears in Error.h on the same function call in
different variations.<br>
- ‘Called C++ object pointer is null’: Third of the
reports happen on placement new operations.<br>
</div>
</div>
</blockquote>
<br>
Yes! That's what i wanted to hear. Put this on the top :)
Great job identifying those top issues!<br>
<br>
I've been noticing placement-new bugs before, but i didn't
ever notice leaks in Error.h being a popular FP, nice catch!
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><font size="4">Proposed solutions for the false
positives</font><br>
One could say creating more assertions could remove
the errors and document the code better. Let think
about the opposite: removing every assertion like
‘assert()’ and ‘LLVM_DEBUG()’[2] could show the
weakness of the Static Analyzer. We cannot force our
users to double or triple the number of assertions
(even it would be very useful). With that, and the new
debug-facilities the door will be open to mitigate the
false positives.<br>
</div>
</div>
</blockquote>
<br>
That depends. When suppressing Static Analyzer false
positives with assertions, some assertions are great to add
anyway as a means of documentation and verification, while
others do indeed look like ridiculous false positive
suppressions that clearly don't belong here.<br>
<br>
Regardless of having to add an assertion or not, we should
anyway in parallel think whether we could have prevented the
false positive from happening in the first place.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>It is impossible to measure how long does it take
to eliminate a false positive.</div>
</div>
</blockquote>
<br>
*wholeheartedly agrees*<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>If we think about sets of false positives as the
two most common factor is already known, we could
define more sets. We have to start the work from the
highest set. The workflow is the following: pick the
most common false positive, if it is necessary improve
the debugging facilities, mitigate the error, document
that to LLVM Bugzilla, inject assertions to
problematic code, repeat.</div>
</div>
</blockquote>
<br>
Yeah, something like that :)<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
<div>-------------</div>
[1] ExprInspection checks: <a href="https://clang.llvm.org/docs/analyzer/developer-docs/DebugChecks.html#exprinspection-checks" target="_blank">https://clang.llvm.org/docs/analyzer/developer-docs/DebugChecks.html#exprinspection-checks</a><br>
[2] LLVM_DEBUG(): <a href="http://llvm.org/docs/ProgrammersManual.html#the-llvm-debug-macro-and-debug-option" target="_blank">http://llvm.org/docs/ProgrammersManual.html#the-llvm-debug-macro-and-debug-option</a>
<div>-------------</div>
<div><br>
</div>
<div>Any feedback would be really appreciated.</div>
<div><br>
</div>
<div>Thanks you,</div>
<div>Csaba.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div>