Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

StackOverflow while decompiling with 0.150

See original GitHub issue

CFR version

Using official released cfr-0.150.jar

java -jar cfr-0.150.jar --outputdir src\\java --jarfilter "com.<snip>.ed1" classes.jar

Description

Trying to decompile an obscure jar file (same as https://github.com/leibnitz27/cfr/issues/139) I’m getting a reproducible failure on one of the classes:

Processing com.<snip>.ed1
Exception in thread "main" java.lang.StackOverflowError
        at java.util.HashMap.hash(Unknown Source)
        at java.util.HashMap.get(Unknown Source)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:515)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        <continues to repeat this line>

Re-running with the command filtered to only that particular class gives a slightly different traceback

Processing com.<snip>.ed1
Exception in thread "main" java.lang.StackOverflowError
        at org.benf.cfr.reader.util.collections.LazyMap.get(LazyMap.java:40)
        at org.benf.cfr.reader.util.collections.LazyExceptionRetainingMap.get(LazyExceptionRetainingMap.java:19)
        at org.benf.cfr.reader.state.DCCommonState.getClassFile(DCCommonState.java:179)
        at org.benf.cfr.reader.state.DCCommonState.getClassFile(DCCommonState.java:194)
        at org.benf.cfr.reader.bytecode.analysis.types.JavaRefTypeInstance.getClassFile(JavaRefTypeInstance.java:514)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:522)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        at org.benf.cfr.reader.entities.ClassFile.hasAccessibleField(ClassFile.java:524)
        <continues to repeat this line>

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.

Issue Analytics

State:
Created 3 years ago
Comments:7 (4 by maintainers)

Top GitHub Comments

2reactions

leibnitz27commented, Jun 27, 2020

Hah - weird problems like this are why I do this 😉

1reaction

andrewleechcommented, Jun 27, 2020

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!

Top Results From Across the Web

Java try-with-resource implementation done by compiler

I was wondering, when exception occurs how try with resource statement ... Two decompilers gave decent results: CFR 0.150 and Fernflower.

CFR - yet another java decompiler. - benf.org

CFR is a JVM bytecode decompiler - it will decompile modern Java features ... Fix stack overflow when determining original bytecode location (when...

#1772 Decompiling Timeout / Stack Overflow - JPEXS Free ...

When attempting to decompile the "frame 3" action script from the swf file (ppswf.swf) without deobfuscation, the program receives a timeout ...

decompilation - Can obfuscation be applied on certain parts?

When the migration is complete, you will access your Teams at stackoverflowteams.com, and they will no longer appear in the left sidebar on ......

PRADO: Predicting App Adoption by Learning the ... - Zhenpeng Chen

collected from app stores, while the uninstallation ratio is quite private and ... instructions by decompiling the .apk file, because the source code...