<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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"><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_attr">4. Calls to operator!= in foreach
loops -- Are these necessary? Is there any, even articial
cases where this is actually meaningful? This is pretty much
the only non-constructive addition of notes that are
introduced only because of condition tracking.</div>
<div class="gmail_attr"><br>
</div>
<div class="gmail_attr">Example: Notes 13-17, 22-26, 37-41: <a href="http://cc.elte.hu:15001/GSoC2019-July-5/#is-unique=on&run=LLVM%2FClang%20WITH%20condition%20tracking%20FINAL&review-status=Confirmed&review-status=False%20positive&review-status=Intentional&detection-status=New&detection-status=Reopened&detection-status=Unresolved&tab=LLVM%2FClang%20WITH%20condition%20tracking%20FINAL&reportHash=50cc2bed223dc4ba62f46d0665346a5e&report=12743&subtab=50cc2bed223dc4ba62f46d0665346a5e" target="_blank">http://cc.elte.hu:15001/GSoC2019-July-5/#is-unique=on&run=LLVM%2FClang%20WITH%20condition%20tracking%20FINAL&review-status=Confirmed&review-status=False%20positive&review-status=Intentional&detection-status=New&detection-status=Reopened&detection-status=Unresolved&tab=LLVM%2FClang%20WITH%20condition%20tracking%20FINAL&reportHash=50cc2bed223dc4ba62f46d0665346a5e&report=12743&subtab=50cc2bed223dc4ba62f46d0665346a5e</a></div>
</div>
</div>
</blockquote>
<br>
Mmm, yeah, i'd rather skip them. We don't make much sense out of
iterators anyway. I wish IteratorChecker could provide us with
better notes.<br>
<br></div></blockquote><div><br></div><div>I guess I'll fix this up quickly before making this on-by-default. </div></div></div></blockquote><div><br></div><div>That was easier then expected :)</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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"><blockquote type="cite"><div dir="ltr"><div dir="ltr">
<div class="gmail_attr"><br>
</div>
<div class="gmail_attr">3. This one is weird, I'm not yet sure
how this note came about, but yet again, it isn't clear AT
ALL in the original report why CountS will be a source of a
null dereference error. The extra note tells us that CountS
is non-null, but its pointee is.</div>
<div class="gmail_attr"><br>
</div>
<div class="gmail_attr">Note 19: <a href="http://cc.elte.hu:15001/GSoC2019-July-5/#is-unique=on&run=LLVM%2FClang%20WITH%20condition%20tracking%20FINAL&review-status=Confirmed&review-status=False%20positive&review-status=Intentional&detection-status=New&detection-status=Reopened&detection-status=Unresolved&tab=LLVM%2FClang%20WITH%20condition%20tracking%20FINAL&reportHash=356d88cb062474fdf17584bf1451bffc&report=13412&subtab=356d88cb062474fdf17584bf1451bffc" target="_blank">http://cc.elte.hu:15001/GSoC2019-July-5/#is-unique=on&run=LLVM%2FClang%20WITH%20condition%20tracking%20FINAL&review-status=Confirmed&review-status=False%20positive&review-status=Intentional&detection-status=New&detection-status=Reopened&detection-status=Unresolved&tab=LLVM%2FClang%20WITH%20condition%20tracking%20FINAL&reportHash=356d88cb062474fdf17584bf1451bffc&report=13412&subtab=356d88cb062474fdf17584bf1451bffc</a></div>
</div>
</div>
</blockquote>
<br>
You're talking about the "Assuming pointer value is null" thingy? I
suspect that it's a bug and the note is in fact meaningless. See
also <a class="gmail-m_-1901262380460095774gmail-m_5652446046771540064moz-txt-link-freetext" href="https://reviews.llvm.org/D65889?id=214186#inline-590619" target="_blank">https://reviews.llvm.org/D65889?id=214186#inline-590619</a> - i've
seen them before but i suspect that i suddenly see more of them
these days. Generally, i still don't understand the report after
seeing these notes. Even if the notes tell anything about the
pointee, the code they're attached to doesn't.<br>
<br>
I also don't understand why did we bring in the copy-constructor.
Was there an invalidation of all heap going on that also touched
*CountS?<br></div></blockquote><div><br></div><div>The answer lies in the DEBUG notes run: We already track CollectionS to the point where it was initialized, and FindLastStoreBRVisitor tracks the right hand side of it. This will trigger control dependency calculation again, resulting in State being tracked, which leads to that monster of a copy constructor call, where we explain why we believed State to be null. The call to IntrusiveRefCntPtr::operator bool was pruned, but it explains why we placed a note about Obj, because thats what it returns. I do wonder however why it wasn't accompanied with ", which will be (a part of a) condition", I'll take a look.</div></div></div></blockquote><div><br></div><div>This took an unbelievable amount headaches to track (haha) down, but I don't really understand what's happening. I originally thought the that it would help if the debug notes the non-prunable, but the extra information I got didn't help much. It should state that 'Obj' is a condition, and nothing screams from the code as an explanation why it doesn't. I'll try to creduce this little more later on, but its difficult to make an interestingness script for, and since this is the one and only case where this occurred, I'll prioritize more pressing matters for now.</div><div><br></div><div>In any case, here is the report with non-prunable debug notes: <a href="http://cc.elte.hu:15001/GSoC2019-July-5/#run=Missing%20condition%20related%20message%20report&review-status=Unreviewed&review-status=Confirmed&detection-status=New&detection-status=Reopened&detection-status=Unresolved&tab=Missing%20condition%20related%20message%20report&is-unique=on&reportHash=356d88cb062474fdf17584bf1451bffc&report=16665&subtab=356d88cb062474fdf17584bf1451bffc">http://cc.elte.hu:15001/GSoC2019-July-5/#run=Missing%20condition%20related%20message%20report&review-status=Unreviewed&review-status=Confirmed&detection-status=New&detection-status=Reopened&detection-status=Unresolved&tab=Missing%20condition%20related%20message%20report&is-unique=on&reportHash=356d88cb062474fdf17584bf1451bffc&report=16665&subtab=356d88cb062474fdf17584bf1451bffc</a></div></div></div>