[Soot-list] Soot bug?

[Eric Bodden]

Ok, I dug a bit deeper and it seems that the problem is the following.
In the javac setting, the class SootProblem$1 is never used, in the
sense there is never any method invoked on it or field accessed from
it. If I am not mistaken, the class would never get initialized in
that setting and hence, it needs not to be generated. (Does somebody
recall the exact conditions which have to be fulfilled to trigger
class initialization?)

In soot.coffi.Util, we try to load all classes which are in the
constant pool, including SootProblem$1... lines 301ff:

                // Go through the constant pool, forcing all mentioned
classes to be resolved.
                {
                    for(int k = 0; k < coffiClass.constant_pool_count; k++) {
                        if(coffiClass.constant_pool[k] instanceof
CONSTANT_Class_info)
                            {
                                CONSTANT_Class_info c =
(CONSTANT_Class_info) coffiClass.constant_pool[k];

                                String desc = ((CONSTANT_Utf8_info)
(coffiClass.constant_pool[c.name_index])).convert();
                                String name = desc.replace('/', '.');

                                if(name.startsWith("["))

references.add(jimpleTypeOfFieldDescriptor(desc));
                                else
                                    references.add(name);
                            }
                        if(coffiClass.constant_pool[k] instanceof
CONSTANT_Fieldref_info
                        || coffiClass.constant_pool[k] instanceof
CONSTANT_Methodref_info
                        || coffiClass.constant_pool[k] instanceof
CONSTANT_InterfaceMethodref_info) {
                            Type[] types = jimpleTypesOfFieldOrMethodDescriptor(

cp_info.getTypeDescr(coffiClass.constant_pool,k));
                            for (Type element : types) {
                                references.add(element);
                            }
                        }

                    }
                }
            }

So I guess we would have to change that to "add any class to
'references' which is target of an invoke statement or field access
statement. Would that make sense?

Eric

On 02/06/07, Eric Bodden <eric.bodden at mail.mcgill.ca> wrote:
> Hi. Thanks for reporting this. I looked into the problem but it seems
> to be really subtle. Actually I think it is a problem with javac.
>
> I have attached three files,all of which are outputs of javap.
> "eclipse" shows the inner class file, as generated by eclipse. Nothing
> extraordinary here. It looks fine and Soot can process it.
>
> javac however generates, for no apparent reason an anonymous inner
> class SootProblem$1. This is passed to the constructor of the inner
> class as additional argument. I assume that it's meant to be a closure
> to make values of the outer class available. However, this class is
> never generated! In the constructor call, this parameter is simply set
> to null. Still, I don't understand how the class loader can possibly
> accept this as valid bytecode. The type SootProblem$1 definitely seems
> to be missing from the bytecode. I find that really odd. Does anybody
> have any idea?
>
> Eric
>
> On 01/06/07, Mark Friedman <mark.friedman at gmail.com> wrote:
> > I think I've found a bug in Soot.  I've isolated it to the following Java
> > program (the original class was much more complex):
> >
> > public class SootProblem {
> >     public SootProblem()
> >     {
> >         if (false) {
> >             Runnable myRunnable =
> >                     new Runnable() {
> >                         public void run() {}
> >                     };
> >         }
> >         new SootProblemInner();
> >     }
> >
> >     private class SootProblemInner {
> >         int foo;
> >     }
> > }
> >
> > Here is the output of compiling the above file and then running Soot:
> >
> > $ javac SootProblem.java
> > $ ls -l SootProblem*.*
> > -rw-r----- 1 markf eng  483 Jun  1 16:30
> > SootProblem$SootProblemInner.class
> > -rw-r----- 1 markf eng  372 Jun  1 16:30 SootProblem.class
> > -rw-r----- 1 markf eng  329 Jun  1 16:29 SootProblem.java
> > $ java -classpath
> > /home/markf/soot/soot-2708/classes:/home/markf/soot/polyglot-1.3.4/classes:/home/markf/soot/polyglot-1.3.4/cup-classes:/home/markf/soot/jasmin-2708/classes
> > soot.Main -cp /usr/local/java-latest/jre/lib/rt.jar:.
> > -src-prec only-class -O SootProblem
> > Soot started on Fri Jun 01 16:31:14 PDT 2007
> > Exception in thread "main" java.lang.RuntimeException: couldn't find class:
> > SootProblem$1 (is your soot-class-path set properly?)
> >     at soot.SootResolver.bringToHierarchy
> > (SootResolver.java:139)
> >     at
> > soot.SootResolver.bringToSignatures(SootResolver.java:172)
> >     at
> > soot.SootResolver.processResolveWorklist(SootResolver.java:104)
> >     at soot.SootResolver.resolveClass(SootResolver.java :89)
> >     at soot.Scene.loadClass(Scene.java:336)
> >     at soot.Scene.loadClassAndSupport(Scene.java:322)
> >     at soot.Scene.loadNecessaryClass(Scene.java:868)
> >     at soot.Scene.loadNecessaryClasses(Scene.java:887)
> >     at soot.Main.run(Main.java:170)
> >     at soot.Main.main(Main.java:146)
> >
> >
> >
> >
> > _______________________________________________
> > Soot-list mailing list
> > Soot-list at sable.mcgill.ca
> > http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
> >
> >
>
>
> --
> Eric Bodden
> Sable Research Group
> McGill University, Montréal, Canada
>
>


-- 
Eric Bodden
Sable Research Group
McGill University, Montréal, Canada