[Soot-list] Callgraph generation with Paddle

François GOICHON francois.goichon at insa-lyon.fr
Tue May 11 03:40:37 EDT 2010


Hello,

Thank you for your quick answer.
>> However, I am not quite sure whether this really indicates an
>> out-of-memory error. For example, when trying to perform a
>> 1-object-sensitive points-to analysis after callgraph generation, the
>> problematic frame is bdd_makenode+0x75 inside libjeddbuddy and the CR2
>> register is at 0x28442810, which is between two allocated heap segments:
>>     
>
> You can confirm if it is a memory issue if you modify Jedd as follows:
> Edit the method "errorhandler" in jbuddy.c in runtime/csrc in jedd-0.4
> folder to print out the error code. If it prints -1, then buddy is
> running out of memory. -1 is the code for out of memory error in
> buddy.
>   
I think I'm using a binary release of Jedd. I tried to build it from 
source but it seems to have a lot of dependencies that fail to build. 
Anyway, I'll try and eventually it will work.
But if it is an out of memory error, that means that I cannot perform a 
simple object-sensitive points-to analysis with 2 gigs of heap memory ?? 
Would another BDD backend be less expensive ?
>> I am also having a hard time understanding contexts representation
>> within Paddle. For example, while iterating over the object-sensitive
>> callgraph, I obtain such edges:
>>
>> [*] Edge from <AnyObject: void method(AnyObject,int)>
>>        In Context: GlobalAllocNode 17 Any_subtype_of_AnyObject in null
>>    To node: <AnyObject: AnotherObject getObj()>
>>        In Context: GlobalAllocNode 17 Any_subtype_of_AnyObject in null
>>
>>
>> [*] Edge from <AnyObject: void method(AnyObject,int)
>>        In Context: GlobalAllocNode 17 Any_subtype_of_AnyObject in null
>>    To node: <AnyObject: AnotherObject getObj()>
>>        In Context: GlobalAllocNode 17 Any_subtype_of_AnyObject in null
>>
>>
>> Which correspond to the following code:
>>
>> class AnyObject {
>>    private AnotherObject att = new AnotherObject();
>>
>>    public AnotherObject getObj() {
>>        return this.att;
>>    }
>>
>>    void method(AnyObject Untrusted, int i) {
>>        AnotherObject localUntrusted = untrusted.getObj();
>>        AnotherObject localTrusted = this.getObj();
>>       [...]
>>    }
>> }
>>
>> As I understand it, for an object-sensitive analysis, the context
>> attached to these methods should be the allocation site of the receiver
>> objects, which are not allocated at the same line, so why are these
>> contexts similar ?
>>     
>
> Because type of the allocated object in the above two contexts is
> Any_subtype_of_AnyObject, the allocated object definitely does not
> correspond to the new expression in the code snippet above. Some of
> the places where Any_subtype allocation objects are used include
> reflection calls and exceptions.
>
> Saswat
>   
If it does not correspond to the new expression, then what is it ? By 
listing the edges going out of the method method(), I get exactly the 
same result. The code snippet I pasted is just about what my testing 
program is, so there is no reflective calls nor exceptions. Even when 
getting the edges to other methods, I always have this "GlobalAllocNode 
17" and its Any_subtype_of_AnyObject. The callgraph I am using is 
Scene.v().getContextSensitiveCallGraph().

Here are the Soot parameters I used :

"-w", "-p", "cg.paddle" ,  
"enabled:true,bdd:true,backend:buddy,conf:cha,context:objsens,context-heap:true,verbose:true"

Thanks,

François


More information about the Soot-list mailing list