[Soot-list] Potential bug in BDD-based part of Paddle

[Severin Heiniger]

Hi Ondrej,

thanks a lot for clearing that up! There is indeed no point in
materializing ContextAllocDotFields at all, because AbsP2Sets.get will
break them up into the Context and AllocDotField anyway. And the cost
of materializing some of the AllocDotFields of interest should be
acceptable.

Using PointsToAnalysis.reachingObjects(PointsToSet, SootField) is
definitely a viable approach, but I'll probably continue using
AbsP2Set.get(Context, AllocDotField), because the latter allows one to
get the points-to sets of the fields of individual ContextAllocNodes,
rather than a set of them.

Kind regards and thanks for creating such an amazing piece of software,
Severin

On Thu, Apr 21, 2011 at 1:57 PM, Ondrej Lhotak <olhotak at uwaterloo.ca> wrote:
> Not materializing the ContextAllocDotFields is a design decision.
> There are typically very many of them, so creating an object for each
> one would require a lot of memory. One of the reasons for using
> BDDs is that the large set of ContextAllocDotFields can be represented
> implicitly in the BDD, and does not have to be explicit in objects.
>
> The expected way to query the results of Paddle is through the
> PointsToAnalysis interface. In particular, you can first use the
> reachingObjects(Local) method to get the points-to set of main,
> and then use the reachingObjects(PointsToSet, SootField) method
> to get the points-to set of a field of the object(s) that main
> points to.
>
> Ondrej
>
> On Wed, Apr 20, 2011 at 11:26:19AM +0200, Severin Heiniger wrote:
>> Hi,
>>
>> a central step in my context-sensitive analysis performed using Paddle
>> is to get the points-to sets of all fields given a ContextAllocNode as
>> the base. With BDD support disabled, this works as expected, but when
>> enabling BDD support, the iterator returned by
>> ContextAllocNode.fields() doesn't provide any ContextAllocDotFields
>> whatsoever. I was able to reproduce the problem with multiple versions
>> of Soot and types of JVMs. You can find a simple test-case here: [1]
>> It's ready to be run using a Sun-JRE on a 32-bit system (64-bit
>> version is also included).
>>
>> public class MainSubject {
>>        public Object field;
>>        public static void main(String[] args) {
>>                MainSubject main = new MainSubject();
>>                main.field = new Object();
>>        }
>> }
>>
>> Without BDD support, the analysis reports that 'new Object()' is in
>> the points-to set of the field 'new MainSubject().field', while with
>> BDD support, this is not the case. The detailed output:
>>
>> Without BDD support:
>> LocalAllocNode 1 new MainSubject ... in context null:
>>        AllocDotField <MainSubject: java.lang.Object field>:
>>                LocalAllocNode 2 new java.lang.Object ... in context null
>> LocalAllocNode 2 new java.lang.Object ... in context null:
>>
>> With BDD support:
>> LocalAllocNode 1 new MainSubject ... in context null:
>> LocalAllocNode 2 new java.lang.Object ... in context null:
>>
>> I would be extremely grateful if anyone could shed some light on this
>> matter. The success of my current work heavily depends on retrieving
>> the mentioned information efficiently (thus the BDD support).
>>
>> Kind regards,
>> Severin
>>
>> [1] http://dl.dropbox.com/u/232786/paddle-bug.tar.gz
>>  - BDD support can be enabled and disabled in the file 'run'.
>>  - Using Results.v().reachableMethods().contextMethods() instead has
>> no influence on the problem
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
>