Re: Class names in Soot

[Ondrej LHOTAK <olhotak@sable.mcgill.ca>]

It's funny that we just got hit by the same bug, just today. My
preference is to disallow class names with slashes in them altogether,
bacause they are misleading anyway. Specifically, they make the user
think that they are paths relative to the current directory, when in
reality, they are relative to the paths in the classpath.

I will disallow class names with slashes in them in the next version of
Soot unless someone protests.

Ondrej

On Tue, Feb 18, 2003 at 09:41:31PM -0800, Archie Cobbs wrote:
> Hi,
> 
> This is to report a problem I've seen with Soot. The problem turns out
> to be my own fault, however I'd like to suggest that Soot should be
> 'robustified' against my stupid bug :-)
> 
> Soot happily accepts class names of the form "java/lang/Object" instead
> of "java.lang.Object" when loading classes for analysis. However, there
> seems to be at least one subtle bug introduced when they are used. This
> test program demonstrates the problem:
> 
>     import soot.*;
> 
>     public class Test {
> 
> 	public static void main(String[] args) throws Exception {
> 	    new Test();
> 	}
> 
> 	public Test() {
> 	    Scene.v().setSootClassPath(".");
> 	    SootClass c = Scene.v().loadClassAndSupport(getName());
> 	    c.setApplicationClass();
> 	    SootMethod m = (SootMethod)c.getMethods().iterator().next();
> 	    m.retrieveActiveBody();
> 	}
> 
> 	public String getName() {
> 	    //return "java.lang.Object";            // this works!
> 	    return "java/lang/Object";              // this doesn't!
> 	}
>     }
> 
> The program below throws this exception:
> 
> soot.jimple.toolkits.typing.TypeException: Type Error(12)
>   at java.lang.Throwable.fillInStackTrace(Native Method)
>   at java.lang.Throwable.fillInStackTrace(Compiled Code)
>   at java.lang.Throwable.<init>(Compiled Code)
>   at java.lang.Exception.<init>(Exception.java:42)
>   at soot.jimple.toolkits.typing.TypeException.<init>(TypeException.java:39)
>   at soot.jimple.toolkits.typing.TypeVariable.error(TypeVariable.java:532)
>   at soot.jimple.toolkits.typing.TypeNode.lca(Compiled Code)
>   at soot.jimple.toolkits.typing.TypeVariable.fixApprox(Compiled Code)
>   at soot.jimple.toolkits.typing.TypeVariable.computeApprox(Compiled Code)
>   at soot.jimple.toolkits.typing.TypeResolver.compute_approximate_types(Compiled Code)
>   at soot.jimple.toolkits.typing.TypeResolver.compute_array_depth(Compiled Code)
>   at soot.jimple.toolkits.typing.TypeResolver.resolve_step_1(TypeResolver.java:259)
>   at soot.jimple.toolkits.typing.TypeResolver.resolve(TypeResolver.java:181)
>   at soot.jimple.toolkits.typing.TypeAssigner.internalTransform(TypeAssigner.java:59)
>   at soot.BodyTransformer.transform(BodyTransformer.java:58)
>   at soot.BodyTransformer.transform(BodyTransformer.java:80)
>   at soot.jimple.JimpleBody.applyPhaseOptions(JimpleBody.java:118)
>   at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:111)
>   at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:89)
>   at soot.SootMethod.retrieveActiveBody(SootMethod.java:311)
>   at Test.<init>(Test.java:15)
>   at Test.main(Test.java:7)
> 
> If you change the "java/lang/Object" to "java.lang.Object" then it works.
> FYI, this is using Sun's JDK. The above program crashes SableVM:
> 
>   assertion "instruction->stack_and_local_map->stack_size >= 0" failed: file "prepare_code.c", line 1088
> 
> It's nice that Soot accepts the slash version of class names, but perhaps
> it should "canonicalize" all class names passed to it. If this is not
> possible, it should not accept the slash versions.
> 
> Thanks,
> -Archie
> 
> __________________________________________________________________________
> Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com