[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