Re: Constructor call shadow matches - was: [abc] normal tests (+9f,-9p)

The only problem is that this prevents us from applying an
optimization to the hottest method in antlr ;-)

On 11/07/07, Pavel Avgustinov <pavel.avgustinov@magdalen.oxford.ac.uk> wrote:
> The fact that many of the failures are
> VerifyErrors suggests that soot requires the newStmt and the call to
> init to be immediately next to each other, which makes sense (and sounds
> familiar -- I seem to recall being told that this is how it should be,
> though I'm not sure). If that's the case, and weaving splits the two up,
> you'll always have unverifiable code.

No that's not true. The matcher requires it. That's why we have the
constructor folder. It brings the Jimple code to exactly that shape.
In terms of the Verifier it must only be guaranteed that <init> is
called on each newly created object before it is used otherwise.

> In fact, brief experimentation confirms that adding other code (e.g. an
> AssignStatement) in between the newStmt and the init call results in
> unverifiable bytecode.

Yes, because that's a use.

> > Does anybody see a good solution to this? In general I find that it's
> > an interesting question what state a (bound) target object should be
> > in if its constructor threw an advice, anyway.
> In Jimple (at least correctly generated Jimple), the result of the
> newInst is assigned to a new local, and init is immediately called on
> it. If we get an OOME or an exception during construction, we branch out
> and the local remains undefined. Indeed, in my experiments even just
> trying to access the local which holds the result of the newStmt after
> the constructor threw an exception gave a VerifyError. Note that this is
> consistent with the fact that in AspectJ you get the newly constructed
> object "after returning" from a constructor call, but not just "after" one.
>
> To refine my statement at the start: If an exception occurs during the
> (newStmt, init-call) pair, then x is not only "not definitely
> initialised", but in fact "definitely not initialised". In other words,
> the behaviour you tried to fix appears to me to be correct.

Yes, after reading your comment, I think I have to agree. It seemed a
bit odd at first, because one could assume that a constructor *call*
shadow match really only matches the call but because of the
initialization requirement I see now that the new statement has to be
taken into account as well. That's a pity, really...

> PS: Did you run the harness before checking in?

No, admittedly we were so much under time pressure that I did not runt
he complete harness and relied on the nightly build catching possible
side-effects (which it did). I did run the tracematch tests but those
did not cause any failure.

Eric

-- 
Eric Bodden
Sable Research Group
McGill University, Montréal, Canada