Unreachable statement from the Decompiler output

Question

I decompiled an APK file, then tried to compile it and received an "Unreachable statement" compiler error, I want to know is it a obfuscator trick, or decompiler failure? How is it possible? Used dex2jar and Java Decompiler

And here is the decompiled method

public void onSensorChanged(SensorEvent paramSensorEvent) {
    float[] arrayOfFloat = paramSensorEvent.values;
    switch (paramSensorEvent.sensor.getType())
    {
    }
    do
    {
        return;
    } while (this.aDegree == arrayOfFloat[0]);
    this.aDegree = arrayOfFloat[0];
    invalidate();
}

We need to see the original Dalvik bytecode to tell for certain. — Igor Skochinsky, Oct 27 '14 at 18:43
You can never be sure that a decompiler is giving you an accurate approximation of the original code. That is true even when the output is *not* suspicious. Trying to reason about decompiler output which you *know* to be bad or suspicious is pointless at best and dangerous at worst. The best you can do is walk through the bytecode yourself. — Mike Strobel, Oct 27 '14 at 21:01
I often get good decompiled output when compile without pro guard, but with proguard I get inaccurate results, and I thought that messy code is the result of proguard :) — mes, Oct 30 '14 at 11:47
That certainly could be the case. Proguard might rearrange the basic blocks in the bytecode such that the control flow no longer resembles the original `javac` output. Not all decompilers will apply topological sorting to fix this. — Mike Strobel, Nov 03 '14 at 17:14

score 5 · Accepted Answer · answered Oct 27 '14 at 18:04

It's possible because unreachable statement is a useful compile time error, not a runtime check/constraint.

The code that you decompiled might have had something like this originally:

boolean debug = true;
do {
    if(debug) {
        return;
    }
}while (this.aDegree == arrayOfFloat[0]);

The compiler is smart enough to know that debug is always true and doesn't bother with the check in the byte code (for efficiency).

Obviously my example is quite contrived, in reality it was probably more complex (although the end result is the same).

Note that this is just one possible explanation; there are plenty of other reasons why a decompiler might produce bad or suspicious code, and without seeing the bytecode, there is no way to know what the code actually does. — Mike Strobel, Oct 27 '14 at 21:03

Unreachable statement from the Decompiler output

1 Answers1