<div dir="auto"><div>Thank you so much! I was stuck on this for a good couple days. I'll definitely document it in the actual code.<br><div class="gmail_extra"><br><div class="gmail_quote">On 20 Nov 2018 09:12, "Artem Dergachev" <<a href="mailto:noqnoqneo@gmail.com">noqnoqneo@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just looked at some of these. The canonical example here is the following leak:<br>
<br>
1 void foo() {<br>
2 void *x = malloc(1); // note: Memory is allocated<br>
3 void *y = realloc(x, 2); // note: Attempt to reallocate memory<br>
4 if (y) { // note: Assuming 'y' is null<br>
5 // note: Reallocation failed<br>
6 free(y);<br>
7 } else {<br>
8 // warning: Potential leak of memory pointed to by 'x'<br>
9 }<br>
10 }<br>
<br>
The extra state trait is necessary to track the connection between 'x' and 'y' that appears on line 3 and dissolves on line 4. This is, essentially, yet another "Schrodinger" state split: realloc has both succeeded and failed until we check the return value. An eager state split would make null dereference checker unusable in any sort of code that doesn't check for failed reallocs.<br>
<br>
On the other hand, using 'x' after realloc should probably be disallowed unless a prior branch in the code suggested that realloc has failed. And using 'y' would mean that the realloc is assumed to have succeeded.<div class="quoted-text"><br>
<br>
On 11/19/18 5:00 PM, Kristóf Umann wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">
Okay, I'll ask specifics.<br>
<br>
I've spent the better part of last week familiarizing myself with MallocChecker's code in order to eventually split it up (which has been a surprisingly pleasant experience!). In the process of learning how it works, I'm adding doxygen comments to every non-trivial method and non-trivial hackery, from what I can gather from old cfe-dev threads and bug reports.<br>
To me it isn't clear what ReallocPair[1] (added by this[2] commit) does. I can come up with some ideas, but I don't have a grasp on it at all, sadly. The very cryptic boolean out-parameter ReleasedAllocate<wbr>d[3], related to [1], doesn't help this case either. It was added by this[4] commit, but I'm still struggleing to understand what's the happening here.<br>
<br>
[1]<a href="https://github.com/llvm-mirror/clang/blob/master/lib/StaticAnalyzer/Checkers/MallocChecker.cpp#L141" rel="noreferrer" target="_blank">https://github.com/llvm-mir<wbr>ror/clang/blob/master/lib/Stat<wbr>icAnalyzer/Checkers/MallocChec<wbr>ker.cpp#L141</a><br>
[2]<a href="https://github.com/llvm-mirror/clang/commit/c8bb3befcad8cd8fc9556bc265289b07dc3c94c8" rel="noreferrer" target="_blank">https://github.com/llvm-mir<wbr>ror/clang/commit/c8bb3befcad8c<wbr>d8fc9556bc265289b07dc3c94c8</a><br>
[2]<a href="https://github.com/llvm-mirror/clang/blob/master/lib/StaticAnalyzer/Checkers/MallocChecker.cpp#L341" rel="noreferrer" target="_blank">https://github.com/llvm-mir<wbr>ror/clang/blob/master/lib/Stat<wbr>icAnalyzer/Checkers/MallocChec<wbr>ker.cpp#L341</a><br>
[3]<a href="https://github.com/llvm-mirror/clang/commit/55dd956d521d4d650dfd929d67f4b98ede61c0ea" rel="noreferrer" target="_blank">https://github.com/llvm-mir<wbr>ror/clang/commit/55dd956d521d4<wbr>d650dfd929d67f4b98ede61c0ea</a><br>
<br>
<br></div><div class="elided-text">
Artem Dergachev <<a href="mailto:noqnoqneo@gmail.com" target="_blank">noqnoqneo@gmail.com</a> <mailto:<a href="mailto:noqnoqneo@gmail.com" target="_blank">noqnoqneo@gmail.com</a>>> ezt írta (időpont: 2018. nov. 20., K, 1:43):<br>
<br>
Back then Static Analyzer was developed almost exclusively by the<br>
first<br>
generation of Analyzer developers which was a small team at Apple,<br>
none<br>
of which are still active Analyzer developers. I guess they didn't<br>
really need that much open documentation when they could simply<br>
look at<br>
each other's monitor and discuss things on a whiteboard. These<br>
days the<br>
community is much bigger (and i'm much more of a masochist who<br>
does not<br>
feel happy to just sit down and write code, and actively prevents<br>
others<br>
from doing the same, so that everybody knew the taste of code review<br>
pain), so Phabricator turned out to be a spot-on tool.<br>
<br>
But you should ask around for specific things. It might be that<br>
people<br>
have already managed to re-discover the motivation behind certain<br>
solutions.<br>
<br>
On 11/19/18 3:57 PM, Kristóf Umann via cfe-dev wrote:<br>
> Hi!<br>
><br>
> Where can I find design discussions and patch reviews similar to<br>
> <a href="http://reviews.llvm.org" rel="noreferrer" target="_blank">reviews.llvm.org</a> <<a href="http://reviews.llvm.org" rel="noreferrer" target="_blank">http://reviews.llvm.org</a>><br>
<<a href="http://reviews.llvm.org" rel="noreferrer" target="_blank">http://reviews.llvm.org</a>>, but from 2012? There are a<br>
> variety of commits to some files I'm working with in the Static<br>
> Analyzer that could use more explanation. I didn't have any luck<br>
> reading through the cfe-dev and cfe-commits archives.<br>
><br>
> Cheers,<br>
> Kristóf Umann<br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> cfe-dev mailing list<br></div>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> <mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><wbr>><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br>
</blockquote>
<br>
</blockquote></div><br></div></div></div>