[cfe-dev] Reporting a bug found at EndPath at its correct location

[Jordan Rose]

Oops, one key aspect of this scheme that I forgot to mention: you do still put information into the state, and you use that information at the end-of-path nodes to see if there was a problem. You just don't store the nodes where the problem happened, because you know you can find them later. You can take a look at the example SimpleStreamChecker for the simple case, though it doesn't show where the allocation site happened.

Note, also, that a single ExplodedNode may be problematic on multiple paths. For example, I might remember to call free() for an allocated region on one path, but forget on two other early exits. It's not exactly appropriate, then, to report the error at the allocation site, since the problem is path-sensitive.

Jordan


On Sep 17, 2013, at 9:42 , Jordan Rose <jordan_rose at apple.com> wrote:

> Fair enough. We've done a couple things like this before, the main one being leak reports (which need to report their allocation site). In these cases, we don't save the ExplodedNode for the leak event, but instead walk back up the path to the change of state that corresponds to the allocation site. I'm not sure if I've seen any real alternative strategies.
> 
> But there's nothing inherently wrong with doing it your way, other than that you can't clear out your map of ExplodedNodes until the end of analysis (because you don't know all the paths they participate in). There are two caveats I can think of, though:
> 
> - Putting ExplodedNodes in the state is a bad idea (because it means two branches will never be able to re-merge), so instead you could store them in a side table on your checker. This is usually discouraged (you'll notice checker callbacks are const) but if you're careful there should be no problem.
> 
> - Make sure to generate a new node at the point you want to track, even if you don't have any state to change. The analyzer is allowed to recycle ExplodedNodes that have the same state as their predecessor (plus a few other conditions) unless it was explicitly created by a checker.
> 
> I'd see if the "go find the node retroactively" approach works for you before trying the map approach, though.
> 
> Does that help?
> Jordan
> 
> 
> On Sep 17, 2013, at 1:38 , YuvalShahar <yuval.shahar.007 at gmail.com> wrote:
> 
>> Sorry for the misunderstanding. It is just a bad choice of example; of course
>> I cannot correctly solve the issue of unused variables in a path-sensitive
>> check.
>> 
>> However, the issue I AM trying to solve IS path-sensitive:
>> I need to mark many statements in the path and emit my bug reports at end of
>> path.
>> 
>> My questions are about the scheme of creating and saving many ExplodedNodes
>> on the state, and then putting the bug reports on the relevant nodes:
>> - Would this scheme work?
>> - Is it expensive in memory?
>> - Is there a preferred scheme?
>> 
>> Thanks.
>> 
>> 
>> 
>> --
>> View this message in context: http://clang-developers.42468.n3.nabble.com/Reporting-a-bug-found-at-EndPath-at-its-correct-location-tp4034472p4034506.html
>> Sent from the Clang Developers mailing list archive at Nabble.com.
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>