[Soot-list] Instrumenting exceptional edges in CFG

[Bodden, Eric]

Hi Nate.

> 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. =)

Well, I guess Soot's error handling could be better, though...

> 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.

I wonder whether the fall-through branch from label3 to label 4 might be the problem. Along this control flow you are popping an exception off the stack (at label 4) although no exception was at all thrown. This looks wrong to me. I think the basic block after label3 should end in a "goto <end of method>" or wherever it makes sense.

Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20140203/b2d6a2a2/attachment.bin