[Soot-list] Exception Table

[mbatch at cs.mcgill.ca]

Pat,

Sorry - I've been away from email for a few days. I did indeed make that
patch due to a bug that was causing "holes" in the catch blocks, if I
recall correctly. I don't remember the exact scenario, but as far as the
claim that a store instruction will not cause an exception, that may be
true, but you need to account for all throwables - including Errors and
Asynchronous Exceptions.

I can look into this further unless the solution you've checked in solves
people's problems. My patch obviously came about from obfuscation work, so
I can say it might have been odd looking bytecode that I was dealing with
- but it was definitely valid and verifiable bytecode. As noted, javac can
and often does make odd looking bytecode out of constructs like
synchronized blocks, where a catch block catches its own throwables.

Michael

On Wed, July 9, 2008 4:18 pm, Patrick Lam wrote:
> Silviu ANDRICA wrote:
>
>> In the on-line version,
>> http://java.sun.com/docs/books/jvms/second_edition/html/Instructions2.do
>> c.html,
>>
>> there is no mentioning about any exceptions that the instruction might
>> throw.
>
> I don't know, then, if your problem actually causes any issues in
> practice. Nevertheless, I think that the following patch ought to fix the
> problem. When Soot adds the rN := @caughtexception it will now update its
> pointers so that the @caughtexception statement takes the place of the
> statement it got added just before.
>
> This patch sort of seems to work at cross purposes with one of Michael
> Batchelder's commits, the one which changes the insertBefore into an
> insertBeforeNoRedirect. I'd be curious to see if he has any comments on
> this, if he can remember what happened. The relevant revision is 2513.
>
> I've committed the patch.
>
>
> pat
>
> Index: src/soot/coffi/CFG.java
> ===================================================================
> --- src/soot/coffi/CFG.java	(revision 3260)
> +++ src/soot/coffi/CFG.java	(working copy)
> @@ -1372,16 +1372,22 @@
>
>
> newTarget = Jimple.v().newIdentityStmt(local,
> Jimple.v().newCaughtExceptionRef());
>
>
> -			// changed to account for catch blocks which are also part of normal
> control flow -            //units.insertBefore(newTarget, firstTargetStmt);
>  -            ((PatchingChain)units).insertBeforeNoRedirect(newTarget,
> firstTargetStmt); +
> ((PatchingChain)units).insertBeforeNoRedirect(newTarget,
> firstTargetStmt);
>
> targetToHandler.put(firstTargetStmt, newTarget); -            if
> (units.getFirst()!=newTarget) {
> -              Unit prev = (Unit)units.getPredOf(newTarget);
> -              if (prev != null && prev.fallsThrough())
> -
> units.insertAfter(Jimple.v().newGotoStmt(firstTargetStmt), prev); -
> }
> +			if (units.getFirst()!=newTarget) {
> +			    Unit prev = (Unit)units.getPredOf(newTarget);
> +			    if (prev != null && prev.fallsThrough())
> +				units.insertAfter(Jimple.v().newGotoStmt(firstTargetStmt), prev);
> +			}
> +
> +			// Bug reported by Silviu Andrica:
> +			// rN := @caughtexception gets ignored by future
> +			// trap generation.
> +			for (Map.Entry<Instruction,Stmt> e :
> instructionToFirstStmt.entrySet()) { +			    if (e.getValue() ==
> firstTargetStmt) +				e.setValue(newTarget);
> +			}
> }
> }
>
>
>
>
>
>