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

[Artem Dergachev via cfe-dev]

*repeats without overquoting in order to avoid hitting the mailing list 
message length limit*

On 7/23/19 7:29 PM, Artem Dergachev wrote:
> Xerces - DOMRangeImpl.cpp: Ugh, are those "Value assigned to..." notes 
> triggered by invalidation? I have a plan of my own to wipe such notes 
> out (or at least formulate them more carefully), so i guess it's not 
> an action item for you (nor much of a regression), but still ugh. 
> Another thing to think about for those is to suppress the warning 
> entirely when a region that stores is important condition is first 
> assumed to contain false, then invalidated, then assumed to contain true.
>
> Xerces - XMLString.hpp: Mmm, i guess passing unconstrained values as 
> parameters is also not very meaningful. It doesn't look like it's a 
> *big* problem, but i guess it's worth considering fixing eventually.
>
>
> > Assert conditions are not yet ignored, I have a neat solution locally
>
> Just to make sure - do you have a test case with control flow within 
> the condition, eg. `assert((a || b) && "the universe is collapsing")`?
>
>
> On 7/23/19 12:49 PM, Kristóf Umann wrote:
>> I'm happy to delight you all with some more results! I was far more 
>> strict on my judgement this time around, marking a report good when I 
>> genuinely believed that the note made the report better.
>>
>> All the runs were made on monorepo commit 
>> db4e335b8643056f5afa2a0d8d175d95b1fb7e28 with the following patches 
>> applied:
>>
>> BEFORE tracking condition:  Without any changes being made, default 
>> CodeChecker settings.
>> AFTER tracking conditions: Without any changes being made, 
>> track-conditions set to true.
>> AFTER tracking conditions + DEBUG notes:  Without any changes being 
>> made, track-conditions and track-conditions-debug set to true.
>> AFTER linear pruning (or similar run name): [1] applied, 
>> track-conditions set to true
>> AFTER tracking conditions WITH improved moderation: [1, 2, 3, 4] 
>> applied, track-conditions set to true (stupid name but it's gonna 
>> stay like this for now :) )
>> AFTER tracking conditions WITH improved moderation: [1, 2, 3, 4] 
>> applied, track-conditions and track-conditions-debug  set to true
>> [1] https://reviews.llvm.org/D64232[analyzer] Prune calls to 
>> functions with linear CFGs that return a non-zero constrained value
>> [2] https://reviews.llvm.org/D64287 [analyzer] Track the right hand 
>> side of the last store regardless of its value
>>
>> [3] https://reviews.llvm.org/D64270[analyzer][NFC] Prepare visitors 
>> for different tracking kinds
>>
>> [4] https://reviews.llvm.org/D64272[analyzer] Note last writes to a 
>> condition only in a nested stackframe
>>
>>
>> LLVM/Clang (no longer analyzing clang-tools-extra): 
>> http://cc.elte.hu:15001/GSoC2019-July-5/#run=LLVM%2FClang%20AFTER%20condition%20tracking%20WITH%20improved%20moderation&review-status=Confirmed&review-status=False%20positive&review-status=Intentional&detection-status=New&detection-status=Reopened&detection-status=Unresolved&tab=LLVM%2FClang%20AFTER%20condition%20tracking%20WITH%20improved%20moderation&is-unique=on
>>
>> Bitcoin: 
>> http://cc.elte.hu:15001/GSoC2019-July-5/#run=Bitcoint%20AFTER%20condition%20tracking%20WITH%20improved%20moderation&review-status=Confirmed&review-status=False%20positive&review-status=Intentional&detection-status=New&detection-status=Reopened&detection-status=Unresolved&tab=Bitcoint%20AFTER%20condition%20tracking%20WITH%20improved%20moderation&is-unique=on
>>
>> Xerces: 
>> http://cc.elte.hu:15001/GSoC2019-July-5/#run=Xerces%20AFTER%20condition%20tracking%20WITH%20improved%20moderation&review-status=Confirmed&review-status=False%20positive&review-status=Intentional&detection-status=New&detection-status=Reopened&detection-status=Unresolved&tab=Xerces%20AFTER%20condition%20tracking%20WITH%20improved%20moderation&is-unique=on
>>
>> Some conclusions:
>>
>>   * [4] Actually notes last writes in /different/, not /nested/ stack
>>     frames. Gotta fix that.
>>   * [1] Returning an unconstrained value when the function is linear
>>     is *never* meaningful. Not for conditions, not for anything else.
>>     Gotta fix that too. It's worth talking about whether we should
>>     prune these for conditions even if the function isn't linear.
>>   * [1] This one gets rid of almost all the operator bool calls.
>>     Maybe in the rare case it doesn't, we should preserve them? I
>>     always planned to get rid of calls to operator bool, but now I'm
>>     hesitant.
>>   * Assert conditions are not yet ignored, I have a neat solution
>>     locally, but I haven't published or tested it yet.
>>
>> There honestly isn't that much I have on my mind, I think after the 
>> next round of analyses we should be good! I really should've made an 
>> analysis with all the non-condition tracking changes to get an even 
>> better perspective, so I'll do that next time.
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190724/e7012cd7/attachment.html>