[Soot-list] null typing passed to useChecker exception
John Oliver
johno at insightfullogic.com
Thu May 12 11:09:26 EDT 2011
Thank you for the response.
Yes I can recreate it on the nightly build. I have attached my source (I did
modify the example to add a main method).
Thanks again (sorry for double reply I accidentally did not cc the list)
John
On Thu, May 12, 2011 at 3:00 PM, Eric Bodden <
bodden at st.informatik.tu-darmstadt.de> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20110512/ce110244/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UseCheckerException.tar.gz
Type: application/x-gzip
Size: 1235 bytes
Desc: not available
Url : http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20110512/ce110244/attachment-0001.gz
More information about the Soot-list
mailing list