[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