Closed Col-E closed 3 years ago
Interesting, I don't see this (fail, just the ugly behaviour) - can you attach a class file? Attached what I get from ojava18_252. (rename txt -> class as usual)
C:\code\cfr\target\classes>"c:\Program Files\Java\openjdk8\bin"\java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
java -jar cfr-0.151.jar c:\code\cfr_tests\output\ojava_8\org\benf\cfr\tests\SyncTest253.class
/*
* Decompiled with CFR 0.151.
*/
package org.benf.cfr.tests;
public class SyncTest253 {
private static final Object lock = new Object();
private static SyncTest253 e = null;
/*
* WARNING - Removed try catching itself - possible behaviour change.
* Enabled force condition propagation
* Lifted jumps to return sites
*/
public static SyncTest253 getFail1() {
if (e != null) return e;
Class<SyncTest253> clazz = SyncTest253.class;
synchronized (SyncTest253.class) {
e = new SyncTest253();
// ** MonitorExit[var0] (shouldn't be in output)
return e;
}
}
}
Huh, it looks like its something with the config I'm passing then. I assumed the OptionDecoderParam#getDefaultValue()
would yield simple booleans for conditional values it yields a string. Similar issues occur for other values, so the config is all messed up. The default settings work fine as you've found.
I'll sort this on my end, but for reference this is what the faulty assumption generated as a config:
// the rest of the values decoded as expected
"constobf" -> "Value of option 'antiobf'"
"hidebridgemethods" -> "Value of option 'obfattr'"
"obfattr" -> "Value of option 'antiobf'"
"obfcontrol" -> "Value of option 'antiobf'"
"renamedupmembers" -> "Value of option 'rename'"
"renameenumidents" -> "Value of option 'rename'"
"renameillegalidents" -> "Value of option 'rename'"
If I remove my default map population logic with, these bad values aren't passed and it decompiles correctly.
I've cleaned up my map population issue and it still occurred, so I narrowed down what option was causing the behavior change and it looks like just specifying recpass
causes this. I pass it using whatever the ArgumentParam
says is the default, so I didn't anticipate a behavior change like this.
CFR Version
CFR 0.151 (fecd6421a8b9de98ade2b9f9b89caecf4a8c93d8)
Compiler
OpenJDK javac 1.8.0_252
Description
Initially reported in https://github.com/Col-E/Recaf/issues/387 - Having a
synchronized
block operating on a class reference in a simpleif
block causes a crash. When theif
statement is defined inside thesynchronized
block it decompiles correctly (albeit with some warnings).Example
The output:
If we move the
if
statement inside the block:Example.java - Includes some methods with slight modifications to show behavior difference