[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: this poorly optimised bytecode causes soot to crash



Looks like a coffi bug.

dup_x2 has two different behaviours, depending on what is on the top of
the stack. If the top of the stack is a 64-bit value, it copies both
halves of it down. But if it is a 32-bit value, the copies only the top
32-bits of the stack down.

Coffi considers only the first form:

(from soot/coffi/CFG.java)
         case ByteCode.DUP_X2:
         {
            Type topType = typeStack.get(typeStack.topIndex()),
                              secondType = typeStack.get(typeStack.topIndex()-1),
                              thirdType = typeStack.get(typeStack.topIndex()-2);

            typeStack = typeStack.pop().pop().pop();

            typeStack = typeStack.push(topType).push(thirdType).push(secondType).push(topType);
            break;
         }

Are there other bytecodes with this kind of weird behaviour that depends
on the top of stack?

Ondrej

On Fri, Jun 27, 2003 at 01:03:41PM +1200, Rohan Hart wrote:
> Hi, I'm trying soot (2.0.1) out on some bytecode produced from the
> Java-alike language Nice.  However the non-optimal bytecode
> 
>    0 invokestatic #12 <Method long f()>
>    3 new #14 <Class java.lang.Long>
>    6 dup_x2
>    7 dup_x2
>    8 pop
>    9 invokespecial #17 <Method java.lang.Long(long)>
> 
> confuses soot because it thinks it's trying to cast a Long into a
> primitive long.  The result is two
>   soot.jimple.toolkits.typing.TypeException: Type Error(12)
>   at soot.jimple.toolkits.typing.TypeVariable.error(TypeVariable.java:527)
>   at soot.jimple.toolkits.typing.TypeNode.lca(TypeNode.java:326)
>   at soot.jimple.toolkits.typing.TypeVariable.fixApprox(TypeVariable.java:649)
>   at soot.jimple.toolkits.typing.TypeVariable.computeApprox(TypeVariable.java:548)
>   at soot.jimple.toolkits.typing.TypeResolver.compute_approximate_types(TypeResolver.java:865)
>   at soot.jimple.toolkits.typing.TypeResolver.compute_array_depth(TypeResolver.java:354)
>   at soot.jimple.toolkits.typing.TypeResolver.resolve_step_1(TypeResolver.java:253)
>   at soot.jimple.toolkits.typing.TypeResolver.resolve(TypeResolver.java:177)
>   at soot.jimple.toolkits.typing.TypeAssigner.internalTransform(TypeAssigner.java:57)
>   at soot.BodyTransformer.transform(BodyTransformer.java:51)
>   at soot.Transform.apply(Transform.java:88)
>   at soot.JimpleBodyPack.applyPhaseOptions(JimpleBodyPack.java:68)
>   at soot.JimpleBodyPack.internalApply(JimpleBodyPack.java:116)
>   at soot.Pack.apply(Pack.java:110)
>   at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:115)
>   at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:79)
>   at soot.SootMethod.retrieveActiveBody(SootMethod.java:274)
>   at soot.PackManager.runBodyPacks(PackManager.java:412)
>   at soot.PackManager.runBodyPacks(PackManager.java:282)
>   at soot.PackManager.runPacks(PackManager.java:241)
>   at soot.Main.run(Main.java:172)
>   at soot.Main.main(Main.java:152)
> 
> Here's the (equivalent) bytecode produced by similar code in Java
> 
>    0 new #2 <Class java.lang.Long>
>    3 dup
>    4 invokestatic #3 <Method long f()>
>    7 invokespecial #4 <Method java.lang.Long(long)>
> 
> thanks
> Rohan
>