[Soot-list] Instrumenting exceptional edges in CFG

[Nate Deisinger]

Hi Eric,

Thanks for the tips.  First off, I should clarify that I was well-aware 
the bad Jasmin meant I was generating bad Jimple somewhere - didn't mean 
to imply otherwise, or that this was Soot's fault. =)

I've tried transforming the code to match that invariant by generating 
new traps for instrumented edges that catch the exception, update our 
path counter, and then jump back to the original catch block, skipping 
over the exception identity statement there.  Unfortunately, this method 
doesn't seem to work either, even in the degenerate case where only one 
block is trapped to begin with and we instrument that edge, meaning we 
can just adjust where the original trap points.

To clarify, here's the relevant Jimple code generated right now for said 
degenerate case:

// Initialization code goes here
      label0:
         nop;
         temp$0 = args;
         temp$1 = 0;
         temp$2 = temp$0[temp$1];
         temp$3 = staticinvoke <java.lang.Integer: int 
parseInt(java.lang.String)>(temp$2);
         goto label3;

      label1:
         nop;
         e := @caughtexception;

      label2:
         temp$4 = <java.lang.System: java.io.PrintStream out>;
         virtualinvoke temp$4.<java.io.PrintStream: void 
println(java.lang.String)>("ArrayIndexOutOfBoundsException!");
         nop;
         goto label3;

      label3:
         nop;
         virtualinvoke basicTry__PT_holder.<PathTrace: void close()>();
         return;

         nop;

      label4:
         e := @caughtexception;
         _____BL_temporary_long = basicTry__PT_holder.<PathTrace: long 
recentPath>;
         _____BL_temporary_long = _____BL_temporary_long + 1L;
         basicTry__PT_holder.<PathTrace: long recentPath> = 
_____BL_temporary_long;
         goto label2;

         catch java.lang.ArrayIndexOutOfBoundsException from label0 to 
label1 with label4;
     }

Where originally label1 would have been the start of the catch block, 
and label4 is the new catch block generated for instrumentation 
purposes.  I've observed two behaviors here:
-If I leave the " e := @caughtexception;" in label1, Jasmin generation 
fails due to negative stack height at that statement. This is actually 
expected, as there are no traps treating that block as a catch block, so 
I assume Jasmin detects this case and correctly fails due to it being 
impossible for an exception to be on the stack at that point.
-However, removing that statement still results in Jasmin generation 
failing, again due to negative stack height, at the " e := 
@caughtexception;" of label4.  (Or more precisely, store.r e).

Any ideas on what might be causing this? It's almost like it doesn't 
think there's an exception on the stack at the handler.

Thanks,
Nate

On 02/02/2014 07:12 AM, Bodden, Eric wrote:
> Hi Nate.
>
>
>> Unfortunately, doing so causes bytecode generation to fail, as negative
>> stack height is attained while generating Jasmin:
> When Jasmin is having trouble this is in almost 100% of the cases an indication that the Jimple code from which the Jasmin is generated is already ill-formed. In your case I am pretty sure that Soot expects that the first non-nop statement within a trap is an identity statement of the form e := @caughtexception. In your case this invariant no longer holds. Would it be possible to transform the code such that it does not break that invariant?
>
> Note that this is not a Soot problem. In Java, within the catch block the exception _will_ be lying on the stack and hence has to be popped off the stack. That's why the identity statement is required.
>
> Eric