[Soot-list] tracking down class-resolver problems

[Chris Pickett]

Will Benton wrote:
> Thanks, Chris!  I'll check the wiki.

There are two different pages about the resolver, I just don't remember 
what the addresses are.  One is an FAQ, the other is more detailed.

>> Also, did you try grepping for the class name?
> 
> Oddly, some of the classes reference this SAXmyHandler class -- it may 
> be something weird in my environment (although I tried to build DaCapo 
> in a clean way), but I'm checking to see if the problem goes away if I 
> remove those classes.

I don't know.  Let us know what you find out.

>> 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.
> 
> I did notice that none of the org.hsqldb classes got analyzed unless I 
> specified them explicitly on the command-line; does this have the same 
> effect?

No, Soot won't include the edges in it's callgraph.  We checked.

> btw, are there any other DaCapo gotchas?

We had problems with xalan being included in the Sun and IBM JDK.  If 
you are transforming it, be careful that when you run it, you get the 
modified version.  -Xbootclasspath:/p may or may not help; I recall we 
had to strip it out of rt.jar, but we might have had a special situation.

I'm sure there are others, depending on the complexity or moreover 
abnormality of what you want to do.  Eric has had problems with bloat 
operating on its own classes.  So far I've only heavily used lusearch, 
hsqldb, and xalan since those are the only ones with multithreaded 
workloads.

Chris