[Soot-list] Is this a soot bug?

[John Jorgensen]

>>>>> "Luca" == Luca  <mitch_ing at yahoo.it> writes:
    Luca> which one of the two collections of class files
    Luca> did you run?

Both, now (I think I only tried classes1.1.1.tgz when I first
answered you, but I just made sure that I ran against both
classes1.1.1.tgz and soucesANDclasses1.2.0.tgz).

    Luca> I am using Soot as a library to build a slicer for
    Luca> aspectJ programs, but it is still WIP.  Clinit
    Luca> methods analysis is still not implemented, because
    Luca> they are recursive and I still didn't implement
    Luca> recursion analysis, so we don't load them, but
    Luca> with bytecode produced by the aspectj 1.1.1
    Luca> compiler it used to work!

You may not have deliberately loaded the clinit method, but Soot's
messages indicate that it was trying to analyze a clinit.  Maybe
some change in the code generated by aspectj results in the clinit's
now appearing in your call graphs.  I'm only speculating.

    Luca> Anyway another project member gets another kind of
    Luca> problem using bytecode produced buy aspectJ
    Luca> compiler 1.1.1: 
    Luca> Applying phase jb.uce to <T: void set_temp(int)>.  
    Luca> Exception in thread "main" java.lang.NullPointerException 
    Luca> at soot.AnySubType.v(AnySubType.java:44)
    Luca> at soot.toolkits.exceptions.ThrowableSet$Manager.<init>(ThrowableSet.java:239)
    Luca> at soot.Singletons.soot_toolkits_exceptions_ThrowableSet_Manager(Singletons.java:1005)
    .
    .
    .

This exception is essentially the same as the one you reported
before:  the construction of an ExceptionalUnitGraph is being
interrupted because AnySubType.v("java.lang.ClassFormatError") is
throughing a NullPointerException, which is likely caused by
java.lang.ClassFormatError not being preloaded before you load
the class.

I have two, admittedly vague, suggestions:

- ensure that whatever method you are using to initialize Soot
  before loading the classes you want to analyze is somehow
  accomplishing the work that is performed by
  Scene.loadBasicClasses() (and not somehow undoing it
  afterwards, not that I have any idea if that is even possible).

- to avoid figuring out what parts of Soot need to be initialized
  before performing your analyses, consider implementing your
  analyses as packs to be added to existing stages of Soot, then
  call soot.Main.main() to initialize Soot and run your analyses.
  See soot.tools.CFGViewer() for a relatively simple example of
  such an approach.  Admittedly, your analysis may not fit neatly
  into the form of a Soot transformation, in which case this idea
  is of no use.

There have been occasional discussions on soot-list about the
steps required to use Soot as a library, so you might want to
look in the archives for notes about other people's experience
(and complaints, if I recall correctly :-)).  See, for example,
http://www.sable.mcgill.ca/pipermail/soot-list/2005-March/000172.html
which refers to two useful articles describing the how classes get
loaded: 

  https://svn.sable.mcgill.ca/wiki/index.php/ClassResolver
  https://svn.sable.mcgill.ca/wiki/index.php/ClassResolverFAQ