Exception while retrieving the body

[John Jorgensen <jorgnsn@lcd.uregina.ca>]

    vranganath> I am using soot 2.1.0 and I get the following
    vranganath> exception when retrieving the body for the
    vranganath> attached class. I used jikes to compile the
    vranganath> attached source.

    vranganath> Warning: target of a branch is null
    vranganath> 84: tableswitch[84]
    vranganath> tableswitch($stack0) {     case 301: goto goto [?= $stack0 = l0];     
    vranganath> case 302: goto null;     default:
    vranganath>  goto $stack0 = new java.io.BufferedInputStream; }successor: null
    vranganath> java.lang.NullPointerException
    vranganath> 	.
    vranganath> 	.
    vranganath> 	.
    vranganath> Any ideas what may be wrong? If a particular fix
    vranganath> since v2.1.0 addresses this issue, can you please
    vranganath> point out this fix?

The problem with still exists in the current soot trunk (and
still only on jikes-generated code). 

So far, I have only confirmed I can duplicate the bug.  Even that
process was intriguing, though, since the bug manifests itself at
different points depending on which command line options you
use. With no options, the development soot produces an exception
at a point analogous to that you reported for soot 2.0.1:

  Warning: target of a branch is null
  84: tableswitch[84]
  Exception in thread "main" java.lang.NullPointerException
        at soot.toolkits.graph.UnitGraph.buildUnexceptionalEdges(UnitGraph.java:129)
        at soot.toolkits.graph.ExceptionalUnitGraph.initialize(ExceptionalUnitGraph.java:244)
        at soot.toolkits.graph.ExceptionalUnitGraph.<init>(ExceptionalUnitGraph.java:146)
        at soot.toolkits.graph.ExceptionalUnitGraph.<init>(ExceptionalUnitGraph.java:178)
        at soot.toolkits.scalar.LocalSplitter.internalTransform(LocalSplitter.java:78)
        at soot.BodyTransformer.transform(BodyTransformer.java:51)
        at soot.Transform.apply(Transform.java:98)
        at soot.JimpleBodyPack.applyPhaseOptions(JimpleBodyPack.java:61)
        at soot.JimpleBodyPack.internalApply(JimpleBodyPack.java:93)
        at soot.Pack.apply(Pack.java:120)
        at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:115)
        at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:80)
        at soot.SootMethod.retrieveActiveBody(SootMethod.java:303)
        at soot.PackManager.retrieveAllBodies(PackManager.java:677)
        at soot.PackManager.runPacks(PackManager.java:297)
        at soot.Main.run(Main.java:180)
        at soot.Main.main(Main.java:154)

But when I added the "--dump-body ALL" option, in an attempt to
see the intermediate representation of the method triggering the
problem, the exception occurred within the code that tries to dump
the intermediate form:

  Warning: target of a branch is null
  84: tableswitch[84]
  Exception in thread "main" java.lang.RuntimeException: Unitbox
  points outside unitChain! to unit : null
        at soot.Body.validateUnitBoxes(Body.java:253)
        at soot.Body.validate(Body.java:200)
        at soot.jimple.JimpleBody.validate(JimpleBody.java:67)
        at soot.Printer.printTo(Printer.java:311)
        at soot.util.PhaseDumper.dumpBody(PhaseDumper.java:222)
        at soot.util.PhaseDumper.dumpBefore(PhaseDumper.java:267)
        at soot.Pack.apply(Pack.java:119)
        at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:115)
        at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:80)
        at soot.SootMethod.retrieveActiveBody(SootMethod.java:303)
        at soot.PackManager.retrieveAllBodies(PackManager.java:677)
        at soot.PackManager.runPacks(PackManager.java:297)
        at soot.Main.run(Main.java:180)
        at soot.Main.main(Main.java:154)

This suggests that there's something in the jikes output for
FetchRobotsTXTTaskImpl.execute() that causes soot to generate bad
jimple right at the outset. Presumably this has something to do
with the fact that the jikes-generated code has a tableswitch
where javac uses a lookupswitch (that's the only difference
between the code generated by javac and jikes that jumps out at
you).

I may not have much time to look at this before the weekend.  For
anybody who wants to try to duplicate the bug in the meantime: In
order to resolve the references in the file Venkatesh submitted,
I downloaded the complete jspider package from
http://j-spider.sourceforge.net/download/index.html and compiled
with jikes-1.21. The binaries that came in
jspider-src-0.5.0-dev.zip (presumably compiled with javac) did
not exhibit the problem.