[Soot-list] Exceptions in IFDS Analysis

Henddher Pedroza hpedro2 at uic.edu
Fri Apr 5 18:04:21 EDT 2013


Thanks Marc-Andre.

No, I am not using that option. Should I?

Is soot analyzing and loading all classes and their respective methods? 
(I thought all java* and other "standard" packages will be excluded "automatically")

I am using "-w", "-pp" and "-process-dir"

- Henddher

On Apr 5, 2013, at 4:58 PM, Marc-André Laverdière-Papineau <marc-andre.laverdiere-papineau at polymtl.ca> wrote:

> Hello,
> 
> This is weird.
> For such a small project, I don't see why you'd need that much memory. 
> Are you using -no-bodies-for-excluded?
> 
> I used to have analyses that blew up my memory until I turned that 
> option on.
> 
> Marc-André Laverdière-Papineau
> Doctorant - PhD Candidate
> 
> On 13-04-05 04:44 PM, Henddher Pedroza wrote:
>> I was getting strange exceptions also, and after letting it run pass the exceptions, it ended up with OOE.
>> I bumped up the heap size to 4000M and it seems to be ok now.
>> 
>> -Xmx4000m
>> 
>> I am actually running IDE Main + IFDSUninitializedVariables on a dummy stand-alone java app with 5 classes (~5K uncompressed)
>> 
>> But, I don't know :(
>> 
>> On Apr 5, 2013, at 3:35 PM, Marc-André Laverdière-Papineau <marc-andre.laverdiere-papineau at polymtl.ca> wrote:
>> 
>>> Hello,
>>> 
>>> I have been getting this problem only recently, and I am not sure what I
>>> am doing wrong.
>>> 
>>> I am getting exceptions like these:
>>> 
>>> Exception in thread "pool-2-thread-1" java.lang.NullPointerException
>>> 	at
>>> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191)
>>> 	at com.google.common.cache.LocalCache.get(LocalCache.java:3989)
>>> 	at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3994)
>>> 	at
>>> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4878)
>>> 	at
>>> com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4884)
>>> 	at
>>> soot.jimple.toolkits.ide.icfg.JimpleBasedInterproceduralCFG.getOrCreateUnitGraph(JimpleBasedInterproceduralCFG.java:174)
>>> 	at
>>> soot.jimple.toolkits.ide.icfg.JimpleBasedInterproceduralCFG.isExitStmt(JimpleBasedInterproceduralCFG.java:199)
>>> 
>>> and
>>> 
>>> Exception in thread "main" java.lang.NullPointerException
>>> 	at
>>> soot.jimple.toolkits.ide.icfg.JimpleBasedInterproceduralCFG.getMethodOf(JimpleBasedInterproceduralCFG.java:163)
>>> 	at
>>> soot.jimple.toolkits.ide.icfg.JimpleBasedInterproceduralCFG.getMethodOf(JimpleBasedInterproceduralCFG.java:65)
>>> 	at heros.solver.IDESolver.setVal(IDESolver.java:576)
>>> 
>>> Digging a bit, I am seeing that unitToOwner returns null in this chunk
>>> of code, when u is an IdentityStmt.
>>> 
>>> 	@Override
>>> 	public boolean isExitStmt(Unit u) {
>>> 		Body body = unitToOwner.get(u);
>>> 		DirectedGraph<Unit> unitGraph = getOrCreateUnitGraph(body);
>>> 		return unitGraph.getTails().contains(u);
>>> 	}
>>> 
>>> Even when I breakpoint and look down in the trace, I am unable to
>>> determine where it is coming from, or why is it that a given method is
>>> analyzed or not. You can say that troubleshooting is hard :(
>>> 
>>> Has anybody else ever dealt with this? How did you fix it?
>>> 
>>> P.S. I am running with some exclusions and -no-bodies-for-excluded
>>> P.P.S I tried feeding all the units in the application classes in
>>> unitToOwner and I'm still hitting this problem.
>>> 
>>> Regards,
>>> 
>>> --
>>> Marc-André Laverdière-Papineau
>>> Doctorant - PhD Candidate
>>> _______________________________________________
>>> Soot-list mailing list
>>> Soot-list at sable.mcgill.ca
>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>> 
>> 
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list



More information about the Soot-list mailing list