[cfe-dev] [analyzer] Tracking values for generating bug reports

[Kristóf Umann via cfe-dev]

>
> 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.
>>
>> Example: Notes 13-17, 22-26, 37-41:
>> 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
>>
>>
>> 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.
>>
>>
> I guess I'll fix this up quickly before making this on-by-default.
>

That was easier then expected :)

>
>> 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.
>>
>> Note 19:
>> 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
>>
>>
>> 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
>> https://reviews.llvm.org/D65889?id=214186#inline-590619 - 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.
>>
>> 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?
>>
>
> 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.
>

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.

In any case, here is the report with non-prunable debug notes:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190813/a8e14e5f/attachment.html>