[Soot-list] null typing passed to useChecker exception

[Eric Bodden]

Hi John.

Thanks for the detailed explanation. I am having problems reproducing
the problem with the current version of Soot, though.

Could you try with this nightly build?
http://plg.uwaterloo.ca/~olhotak/build/sootclasses.jar

If the problem still persists, could you send us the class file and
exact command line arguments to trigger this exception?

Eric

On 11 May 2011 23:23, John Oliver <johno at insightfullogic.com> wrote:
> Hello.
>
> I am trying to use soot but I am having issues similar to the bug
> https://svn.sable.mcgill.ca/bugzilla/show_bug.cgi?id=109
>
> My test code is as follows:
>
> ==============
> package test;
>
> import java.util.Arrays;
> import java.util.Collection;
>
> public class Loops {
>
>     public void loops() {
>         int[] l1 = new int[]{};
>         Collection<String> l2 = Arrays.asList();
>
>         for(String o:l2) {
>             for(int j:l1) {
>             }
>         }
>     }
> }
> ==============
>
> And I get the following stack trace:
>
> java.lang.Exception: null typing passed to useChecker
>     at
> soot.jimple.toolkits.typing.fast.UseChecker.check(UseChecker.java:50)
>     at
> soot.jimple.toolkits.typing.fast.TypeResolver.insertCasts(TypeResolver.java:345)
>     at
> soot.jimple.toolkits.typing.fast.TypeResolver.inferTypes(TypeResolver.java:124)
>     at
> soot.jimple.toolkits.typing.TypeAssigner.internalTransform(TypeAssigner.java:101)
>     at soot.BodyTransformer.transform(BodyTransformer.java:51)
>     at soot.Transform.apply(Transform.java:104)
>     at soot.JimpleBodyPack.applyPhaseOptions(JimpleBodyPack.java:66)
>     at soot.JimpleBodyPack.internalApply(JimpleBodyPack.java:89)
>     at soot.Pack.apply(Pack.java:124)
>     at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:117)
>     at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:82)
>     at soot.SootMethod.retrieveActiveBody(SootMethod.java:315)
>     at
> soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.processNewMethod(OnFlyCallGraphBuilder.java:531)
>     at
> soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.processReachables(OnFlyCallGraphBuilder.java:426)
>     at
> soot.jimple.toolkits.callgraph.CallGraphBuilder.build(CallGraphBuilder.java:84)
>     at
> soot.jimple.toolkits.callgraph.CHATransformer.internalTransform(CHATransformer.java:43)
>     at soot.SceneTransformer.transform(SceneTransformer.java:39)
>     at soot.SceneTransformer.transform(SceneTransformer.java:45)
>     at soot.SceneTransformer.transform(SceneTransformer.java:50)
>
>
> I was wondering if anyone had run into this problem or found any solutions?
>
> I am using jdk 1.6.9_23 and the latest svn for soot.
>
> Having a bit of a dig around, for my example it appears to be a problem
> with soot resolving iterator types when using the original-names. When
> compiled with -g:source,lines,vars, the compiled class seem to associate
> the name i$ to the iterator of the loops. For the first loop i$ is an
> java.util.Iterator for the second loop it is an int that is being use as
> an array index.
>
> ============
> Output from javap -l :
>
>   LocalVariableTable:
>    Start  Length  Slot  Name   Signature
>    64      0      8    j       I
>    42      28      5    arr$       [I
>    47      23      6    len$       I
>    50      20      7    i$       I
>    39      31      4    o       Ljava/lang/String;
>    19      54      3    i$       Ljava/util/Iterator;
>    0      74      0    this       Ltest/Loops;
>    4      70      1    l1       [I
>    12      62      2    l2       Ljava/util/Collection;
>
> ===========
>
> getLocalForIndex in soot.coffi.Util then seems to mistakenly label them
> as the same JimpleLocal due to them having the same name. This method
> contains a comment "Feng asks: why this is necessary? it does wrong
> thing for searching local variable names. It is going to be verified
> with plam.", does anyone know if this is the issue he is referring to?
>
> If use-original-names is set to false then getLocalForIndex simply
> assigns a name and everything works fine.
>
> Does anyone have any solution to this? Unfortunately I have failed at
> fixing the problem and my alternative solution is to allow names to be
> generated then maintain a separate map mapping from the Local to the
> actual variable name. This however does seem like a bit of a hack and
> thought I would ask to see if anyone else had any ideas.
>
> Thanks for any help you can give.
>
> John Oliver
>
>
>
>
>
>
>
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>



-- 
Dr. Eric Bodden, http://bodden.de/
Principal Investigator in Secure Services at CASED
Coordinator of the CASED Advisory Board of Study Affairs
PostDoc at Software Technology Group, Technische Universität Darmstadt
Tel: +49 6151 16-5478    Fax: +49 6151 16-5410
Mailing Address: S2|02 A209, Hochschulstraße 10, 64289 Darmstadt