StackOverflow while decompiling with 0.150 #191
Comments
|
I've just re-tested with a build from master ( 7b97993 ) and get this traceback with slightly updated file lines instead: |
|
Oh ouch. The only way I can see of that happening is if the classfile is its own base class (Or I've really messed up and somehow inferred that). Pretty cute if someone's released one of those..... Would be very handy to get an example, if not, can you check the class hierarchy (with, say, javap)? |
|
Hi, I was hoping it'd be an obvious/simple issue once pointed to the lines in the traceback. Turns out not, it's again something strange with the obfuscator used on this codebase. There's a few other classes in the same app that do the same thing. I've taken a look at some of them in Bytecode Viewer. Turns out the same class files make procyon fail too. Fernflower gives me public abstract class ed1 {
public final w40 a;
public final q11 b;
public final w31 c;
public ed1(w31 var1) {
w40 var2 = new w40((byte)1, (byte)0);
super();
this.a = var2;
this.c = var1;
this.b = q11.a;
}
public ed1(w31 var1, w40 var2) {
this.a = var2;
this.c = var1;
this.b = q11.a;
}However, the older cfr-0.143.jar included there gives public abstract class ed1<T>
extends ed1<T> {
public final w40 a;
public final q11 b;
public final w31 c;
public ed1(w31 w312) {
w40 w402 = new w40(1, 0);
this.a = w402;
this.c = w312;
this.b = q11.a;
}
public ed1(w31 w312, w40 w402) {
this.a = w402;
this.c = w312;
this.b = q11.a;
}so, yeah, there's that. Based on the smali of the failing class above I've written a new failing example jar attached, renamed to zip |
|
Great example, thanks. I try so hard not to trust (or, as Reagan said, "Trust, but verify" :) ) non-vital info - sneaking an illegal super in via a signature is crafty - hadn't considered that! We now get |
|
Nicely, this didn't fire once on my entire corpus of other tests ;) |
|
Awesome, nice work thanks! Yeah the problem with unit testing is no matter how good you think your coverage is, you can still only test for usages and bugs you know of, but all to often there's someone trying to use/trip you up in a new and weird way. PS please don't feel any pressure to fix issues like this when they seem to be only caused by this weird obfuscator, but if they're interesting I'm more than happy to give as much info as possible! |
|
Hah - weird problems like this are why I do this ;) |
CFR version
Using official released cfr-0.150.jar
Description
Trying to decompile an obscure jar file (same as #139) I'm getting a reproducible failure on one of the classes:
Re-running with the command filtered to only that particular class gives a slightly different traceback
I'm not personally blocked by this, I 'm working around the issue by filtering around the problematic class, eg
--jarfilter "com.<snip>.(?!ed1)"Example
The class causing this is not suitable for sharing here.
The text was updated successfully, but these errors were encountered: