[Soot-list] Is this a soot bug?

John Jorgensen jorgnsn at lcd.uregina.ca
Sat Jun 25 17:44:35 EDT 2005



    Luca> I am using soot as a library.  Before trying to
    Luca> build call graph I load class and support for each
    Luca> class I want to analyze.

    Luca> I will attach sources of the files I try to
    Luca> analyze, class files I built using eclipse AJDT
    Luca> 1.2.0 and class files built using aspectJ compiler
    Luca> 1.1.1, if asked, and I wll send a private mail.

I was able to run "soot -w --app Main" on the class files you
sent without any exceptions being thrown, using both release
2.2.1 of Soot, and the current source checked out of the
repository.  So something in the way you are calling Soot is
exposing the bug.

Now I find myself out of my depth...  I offered to lend a hand
because the exception you reported arose in the course of
building an ExceptionalUnitGraph, which I know something about.
Unfortunately, I know nothing about using Soot as a library, or
about building call graphs.  I can only try to provide some basic
advice, based on the stack trace you provided.

The immediate cause of the NullPointerException thrown by
soot.AnySubtype.v() seems most likely to be that nothing had
ensured that the the class "java.lang.ClassFormatError" was
loaded before an attempt was made to build an
ExceptionalUnitGraph (the ThrowAnalysis classes used to build
ExceptionalUnitGraph need to be able to say that instructions
which may cause a class to be loaded might throw
AnySubtype.v("java.lang.ClassFormatError")).

But java.lang.ClassFormatError gets loaded as part of
Scene.addSootBasicClasses(), called out of Scene's constructor,
and it seems unlikely that you have succeeded in getting soot to
work without constructing a Scene.  Moreover, the verbose output
shows that your application has succeeded in building other
ExceptionalUnitGraphs, which should have required executing the
same instruction as threw the exception when applied to building
a graph to split locals in <TInvariant: void <clinit>()>.

But maybe you are using G.reset(), or some other method, to start
afresh for each method.  So, is there some reason that the code
you use to call into soot would have treated <clinit> (the class
initializer) differently than it treated the other methods, so
that the "java.lang.ClassFormatError" didn't get loaded the way
it was for the other methods?

-- 
John Jorgensen	LCD System Administrator  jorgnsn at lcd.uregina.ca
                                          306.337.2344



More information about the Soot-list mailing list