[Soot-list] Parsing Soot class files fails with NullPointerException

[Eric Bodden]

Hi Heejong.

Thanks for the detailed information. It turns out that the map is not
the problem. The error was instead indeed caused by
-allow-phantom-refs. When this option is set, we must allow the
resolveNonSpecial method to allow a phantom method:

68 *           if( m.isConcrete() || m.isNative() ) {
69                 ret = cls.getMethod( subSig );
70             }

must change to:

68 *           if( m.isConcrete() || m.isNative() || m.isPhantom()) {
69                 ret = cls.getMethod( subSig );
70             }

This is working for me now. I have committed this fix.

Eric

--
Dr. Eric Bodden
Software Technology Group, Technische Universität Darmstadt, Germany
Tel: +49 6151 16-5478    Fax: +49 6151 16-5410
Mailing Address: S2|02 A209, Hochschulstraße 10, 64289 Darmstadt



On 1 June 2010 07:05, Heejong Lee <heejong at gmail.com> wrote:
> Thanks for the reply.
> I ran the debugger and figured out resolveNonSpecial (at
> 57:23:VirtualCalls.java) returned Null. The execution paths are marked as
> asterisks after line numbers:
> 57     public SootMethod resolveNonSpecial( RefType t, NumberedString subSig
> ) {
> 58 *       SmallNumberedMap vtbl = (SmallNumberedMap) typeToVtbl.get( t );
> 59 *       if( vtbl == null ) {
> 60             typeToVtbl.put( t, vtbl =
> 61                     new SmallNumberedMap( Scene.v().getMethodNumberer() )
> );
> 62         }
> 63 *       SootMethod ret = (SootMethod) vtbl.get( subSig );
> 64 *       if( ret != null ) return ret;
> 65 *       SootClass cls = (t).getSootClass();
> 66 *       if( cls.declaresMethod( subSig ) ) {
> 67 *           SootMethod m = cls.getMethod( subSig );
> 68 *           if( m.isConcrete() || m.isNative() ) {
> 69                 ret = cls.getMethod( subSig );
> 70             }
> 71 *       } else {
> 72             if( cls.hasSuperclass() ) {
> 73                 ret = resolveNonSpecial( cls.getSuperclass().getType(),
> subSig );
> 74             }
> 75         }
> 76 *       vtbl.put( subSig, ret );
> 77 *       return ret;
> 78     }
> And from the line 64, variable ret was assigned as Null. What is the role of
> vtbl? In this case, field "array" of vtbl contained NumberedStrings but
> field "values" of that had Null. So vtbl.get() returns Null. Is this
> possible situation? Maybe this problem is related to "-allow-phantom-refs"
> option since the two arguments are {t = java.lang.Object: soot.RefType,
> subSig = java.lang.String toString(): soot.util.NumberedString}. The same
> problem happens when parsing sbt
> 0.7.4(http://code.google.com/p/simple-build-tool/) with the same options.
>> Why do you have soot.Main in the end? Are you trying to analyze Soot
>> itself?
> I just need a mid-size Java program to examine how Soot works :-)
> Regards,
> On Mon, May 31, 2010 at 6:40 PM, Eric Bodden
> <bodden at st.informatik.tu-darmstadt.de> wrote:
>>
>> Hi Heejong.
>>
>> > $ java -jar soot-2.4.0.jar -cp soot-2.4.0.jar -allow-phantom-refs -w -v
>> > soot.Main
>>
>> Why do you have soot.Main in the end? Are you trying to analyze Soot
>> itself?
>>
>> But that should not actually be the cause of this error. It would be
>> nice to have a smaller test case that triggers this Exception.
>>
>> Eric
>
>
>
> --
> Heejong Lee
>
> Associate Research Engineer
> Program Analysis Division
> Fasoo.com, Inc. (www.spa-arrow.com)
>