Hopper returns too much edges than thresher
mirrorwis opened this issue · comments
Same android project.
For thresher,
Call graph stats:
Nodes: 12719
Edges: 28559
Methods: 8737
Bytecode Bytes: 451772
For hopper,
Call graph stats:
Nodes: 52951
Edges: 1422553
Methods: 25109
Bytecode Bytes: 1402449
it looks like hopper try to analyze native java and android code. can we exclude analyze native java code?
Hopper's call graph construction does a better job of being sound than Thresher's, so it's not surprising that the call graphs are larger. However, if you're not concerned with missing code/behaviors, you can specify classes to exclude from call graph construction in an exclusions file and pass them via the -exclusions command line flag.
I got error after I added java.lang.* to exclusions. I don't want to see any possible leaks in native java and android library which I cannot fix on client side.
com.ibm.wala.ipa.cha.ClassHierarchyException: failed to load root <Primordial,Ljava/lang/Object> of class hierarchy
Exclusions eliminate code from being analyzed altogether, which is why you see that error message (WALA can't build class hierarchies without java.lang.Object). Achieving what you're looking for is potentially problematic because almost any leak is going to involve at least some library code--that is, excluding leaks that involve any points-to edge from the Java or Android library is likely to leave you with no leaks. If you want to try this, you can modify AndroidLeakClient to report only leaks where source and sink of each edge belong to the application (this code already does a similar check to rule out leak reports containing weak references). The ClassUtil.isLibrary method would likely be useful for this check.