Avoid Exceptions with Phantom Superclasses #335
Conversation
| @@ -296,7 +296,8 @@ public IClass getSuperclass() { | |||
| computeSuperclass(); | |||
| } | |||
| if (superClass == null && !getReference().equals(TypeReference.JavaLangObject)) { | |||
| throw new NoSuperclassFoundException("No superclass found for " + this + " Superclass name " + superName); | |||
| //throw new NoSuperclassFoundException("No superclass found for " + this + " Superclass name " + superName); | |||
There was a problem hiding this comment.
Why do we need this change? What fails if we continue to throw the exception? I'm hesitant about his change as this code has been throwing an exception for quite a while.
There was a problem hiding this comment.
It throws NoSuperclassFoundException while making CFG when the callee is in a BytecodeClass but has a PhantomClass superclass, as follows:
com.ibm.wala.classLoader.NoSuperclassFoundException: No superclass found for <Application,Landroid/support/v4/view/AsyncLayoutInflater$BasicInflater> Superclass name Landroid/view/LayoutInflater at com.ibm.wala.classLoader.BytecodeClass.getSuperclass(BytecodeClass.java:299) at com.ibm.wala.classLoader.BytecodeClass.getMethod(BytecodeClass.java:464) at com.ibm.wala.classLoader.JavaLanguage.inferInvokeExceptions(JavaLanguage.java:585) at com.ibm.wala.cfg.ShrikeCFG$BasicBlock.addExceptionalEdges(ShrikeCFG.java:287) at com.ibm.wala.cfg.ShrikeCFG$BasicBlock.computeOutgoingEdges(ShrikeCFG.java:243) at com.ibm.wala.cfg.ShrikeCFG$BasicBlock.access$0(ShrikeCFG.java:232) at com.ibm.wala.cfg.ShrikeCFG.computeEdges(ShrikeCFG.java:133) at com.ibm.wala.cfg.ShrikeCFG.<init>(ShrikeCFG.java:76) at com.ibm.wala.cfg.ShrikeCFG.make(ShrikeCFG.java:63) at com.ibm.wala.classLoader.ShrikeIRFactory.makeCFG(ShrikeIRFactory.java:43) at com.ibm.wala.classLoader.ShrikeIRFactory.makeIR(ShrikeIRFactory.java:58) at com.ibm.wala.ssa.DefaultIRFactory.makeIR(DefaultIRFactory.java:69)
There was a problem hiding this comment.
Ah ok; ugh. Thanks for pointing this out. I'd like to think a bit more about the right fix here. It's possible I should just tweak the phantom class hacky implementation to work properly.
|
During testing WALA master, I also stumpled across this issue. This triggers BytecodeClass.computeSuperClass() which executes this line in the else branch: Without checking for possible side-effects, a solution could be that ClassLoaderImpl.lookupClass |
|
@reddr I think my approach to the whole phantom superclass thing was kind of half-baked. I suggest you not rely on it for now and try to get the relevant superclass into your |
|
@msridhar Unfortunately, this seems to be last puzzle piece for my tool to be adapted to WALA master. I'm automatically analyzing apps where it might happen that, in particular, dead code classes contain unresolvable superclasses (i.e., the superclass is part of a library that is not statically linked). When I first stumpled across this issue, I patched it in my custom WALA version in a way that Such an option would be a quick fix to this problem, while if you want to keep references, the PhantomClass concept could be another option. Just let me know if such a dual approach could be interesting for you or whether you just want to have a single clean solution. In the meantime, I still have to use my custom version to resolve this issue. |
|
@reddr I need to think more here. Your use of class hierarchy root makes sense, and I thought about it at first but for some reason concluded it was risky. Now I've forgotten why :-) Let me think more and then we can figure out how to proceed. |
|
Closing as out-of-date. I think we have better phantom superclass handling on master now; see #377 |
@msridhar /cc @lazaroclapp
Building the CFG fails with
NoSuperclassFoundExceptionwhen a callee method has a phantom superclass.Continue by returning
nullinstead.