Infinite loop with recursive JSR

[samczsun]

Yes, I realize that the bytecode is technically illegal because of the recursive JSR, but when decompiling a JAR if an unused class contains this sequence then the entire decompilation will halt.

If you decide that this is out of scope I respect that decision. However, I do feel that this should be fixed

.method public static main : ([Ljava/lang/String;)V 
    .code stack 1024 locals 10
    jsr L1
L1:
    jsr L2
    jsr L1
    return
L2:
    astore_1
    pop
    ret 1
    .end code 
.end method 

[Storyyeller]

The ironic part is that Krakatau originally did strict verification of the bytecode prior to decompilation, but I later took that out since there was little point and it slowed things down slightly. But I guess this is the downside of that.

Note that there are already lots of ways to DOS Krakatau, even with valid bytecode. For example, deeply nested JSRs leads to exponential complexity, as do large highly connected control flow graphs. Luckily those never happen in practice.

[Janmm14]

Can you maybe add a per-class max-loop counter or a max-decompilation time for a class, so the ongoing decompilation of a jar file can continue?

[Storyyeller]

What kind of use case would there be and is it general enough to merit inclusion in Krakatau?