[Soot-list] tracking down class-resolver problems

[Chris Pickett]

Hi William,

There's some documentation on the resolver in the wiki, if it helps 
clarify things.  There should be posts in the archive about it.

Also, did you try grepping for the class name?

Finally, I don't know what the "depzip" target is, but to be sure, 
you're using the right thing, I think you want to use Eric's packaging 
of DaCapo for Soot users available from the DaCapo homepage.

Also, while we're on the topic, you need to hack hsqldb not to load its 
main driver via reflection if Soot is going to analyse it properly.

Hope this helps,
Chris

William Benton wrote:
> Hi all,
> 
> Basically, I'd like some way to see why soot thinks it needs to resolve 
> a particular class -- is there an option to do so?  (I have tried 
> -debug-resolver, but either it does not do what I want or I am not able 
> to interpret its output properly.)  Details follow:
> 
> I'm trying to run soot on the DaCapo suite (built using the "depzip" 
> target).  I'm running into some very odd class resolution problems on 
> several benchmarks, such as this one from chart:
> 
>> Exception in thread "main" java.lang.RuntimeException: couldn't find 
>> class: com.lowagie.text.xml.SAXmyHandler (is your soot-class-path set 
>> properly?)
>>     at soot.SootResolver.bringToHierarchy(SootResolver.java:133)
>>     at soot.SootResolver.bringToSignatures(SootResolver.java:166)
>>     at soot.SootResolver.bringToBodies(SootResolver.java:207)
>>     at soot.SootResolver.processResolveWorklist(SootResolver.java:94)
>>     at soot.SootResolver.resolveClass(SootResolver.java:83)
>>     at soot.Scene.loadClass(Scene.java:367)
>>     at soot.Scene.loadClassAndSupport(Scene.java:352)
>>     at soot.Scene.loadNecessaryClass(Scene.java:899)
>>     at soot.Scene.loadNecessaryClasses(Scene.java:918)
>>     at soot.Main.run(Main.java:169)
>>     at soot.Main.main(Main.java:145)
> 
> Now, my soot-class-path is set properly, containing chart.jar, 
> chart-deps.jar, and the bootstrap class files.  Furthermore, the version 
> of iText (com.lowagie.text) that DaCapo chart is built against doesn't 
> include a SAXmyHandler class.  So I'm curious why or where this class 
> might be referenced from chart.jar or chart-deps.jar -- what's the best 
> way to discover this?
> 
> I'm using the latest subversion release (r3116); I didn't have similar 
> problems with soot 2.2.3 and DaCapo.  I am analyzing against GNU 
> Classpath, but that shouldn't impact classes outside of the standard 
> library.  I've attached a minimal script that reproduces this problem 
> (distilled down from the analyses I'm actually running).
> 
> 
> Thanks for reading!
> wb
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list