[cfe-dev] MemRegion referenced by a LazyCompoundVal not considered as "live"

[Artem Dergachev via cfe-dev]

This behavior is correct. LazyCompoundVal represents a prvalue - 
essentially, a sequence of bytes that compose the data of the object. 
There is no valid code-under-analysis that would extract the historical 
glvalue of an object from an object's prvalue, therefore the parent 
region is not kept alive by the LazyCompoundValue.

The interesting part here, however, is what happens to sub-values of the 
parent region. For instance, if a LazyCompoundVal is taken for an 
ElementRegion with symbolic index, constraints on such index ideally 
need to be tracked in order to extract values from the LazyCompoundVal 
more precisely. Moreover, they need to be as fresh as possible: there's 
benefit in not only simply taking a historical ProgramStateRef at the 
same moment of time in which we took a snapshot of the Store, but taking 
the most recent program state that contained the symbol. This is 
currently a minor bug.

I'm curious about the underlying issue though. You might in fact be 
trying to materialize a temporary, in which case what you need to do is 
to query the ExprEngine's internal state trait that i added recently - 
ExprEngine::getObjectUnderConstruction(..., MaterializeTemporaryExpr, 
...). This trait also keeps the region alive until 
MaterializeTemporaryExpr is resolved. While we don't have a good checker 
interface for that purpose yet, this is the proposed way of obtaining 
C++ object glvalues from prvalues when necessary.

On 6/1/18 6:14 AM, Ádám Balogh via cfe-dev wrote:
>
> Hello,
>
> In a checker I have to clean up some data indexed to MemRegions from 
> the GDM. I do it in checkDeadSymbols where I use isLiveRegion() to 
> check whether a region is live. However, it returns false for memory 
> regions which are referenced by a LazyCompoundVal. Is this correct? If 
> it is, how to save these regions? I could not find a way to search for 
> LazyCompoundVals which reference a MemRegion. Thank you in advance!
>
> Regards,
>
> Ádám
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev