skylot/jadx · error · JadxRuntimeException
Method generation error
Error message
Method generation error
What it means
Thrown by ClassGen.addMethod() when addMethodCode() throws an exception AND the class already has the RESTART_CODEGEN flag set. This means the codegen has already been restarted once (typically due to anonymous class inlining) and the method still fails on the second pass. Rather than silently swallowing the error, jadx escalates it to a fatal runtime exception.
Source
Thrown at jadx-core/src/main/java/jadx/core/codegen/ClassGen.java:348
return true;
}
}
return false;
}
private void addMethod(ICodeWriter code, MethodNode mth) {
if (skipMethod(mth)) {
return;
}
if (code.getLength() != clsDeclOffset) {
code.newLine();
}
int savedIndent = code.getIndent();
try {
addMethodCode(code, mth);
} catch (Exception e) {
if (mth.getParentClass().getTopParentClass().contains(AFlag.RESTART_CODEGEN)) {
throw new JadxRuntimeException("Method generation error", e);
}
mth.addError("Method generation error", e);
CodeGenUtils.addErrors(code, mth);
code.setIndent(savedIndent);
}
}
/**
* Additional checks for inlined methods
*/
private boolean skipMethod(MethodNode mth) {
if (cls.root().getArgs().getDecompilationMode().isSpecial()) {
// show all methods for special decompilation modes
return false;
}
MethodInlineAttr inlineAttr = mth.get(AType.METHOD_INLINE);
if (inlineAttr == null || inlineAttr.notNeeded()) {
return false;View on GitHub (pinned to e738a26571)
Solutions
- Report the method/class to jadx with the full stack trace — this is an internal decompiler limitation.
- Use --decompilation-mode FALLBACK or set JadxArgs.decompilationMode to a simpler mode that avoids aggressive transformations.
- Exclude the problematic class from the decompilation set if only specific classes are needed.
Example fix
// before // JadxArgs args = new JadxArgs(); // args.setDecompilationMode(DecompilationMode.AUTO); // after // args.setDecompilationMode(DecompilationMode.FALLBACK);
Defensive patterns
Strategy: fallback
Validate before calling
// Use a simpler decompilation mode to avoid restart-triggering transforms JadxArgs args = new JadxArgs(); args.setDecompilationMode(DecompilationMode.FALLBACK); // FALLBACK avoids anonymous class inlining and other aggressive transforms // that can trigger RESTART_CODEGEN cycles
Try / catch
try {
jadxDecompiler.decompile();
} catch (JadxRuntimeException e) {
if (e.getMessage().equals("Method generation error")) {
logger.error("Method failed even after codegen restart. Retrying with fallback mode.", e);
// Retry the specific class with fallback mode
args.setDecompilationMode(DecompilationMode.FALLBACK);
// re-decompile
}
throw e;
} Prevention
- For obfuscated or complex apps, start with DecompilationMode.SIMPLE or FALLBACK.
- Report methods that fail after restart to the jadx project.
- Process classes individually to isolate failures rather than failing the entire batch.
When it happens
Trigger: A method that fails to decompile during code generation, where the containing class was already marked for codegen restart (e.g., due to anonymous inner class conversion). The second attempt at addMethodCode() also throws.
Common situations: Complex bytecode patterns in obfuscated apps that trip up codegen twice. Anonymous classes with intricate constructor logic that causes restart and still fails. Edge cases in invoke-custom or lambda processing.
Related errors
- Code generation error after restart
- Code generation error
- Error generate insn:
- Constructor 'self' invoke must be removed!
- Anonymous inner class unlimited recursion detected. Convert
AI-assisted analysis of skylot/jadx@e738a26571 (2026-08-14).
Data as JSON: /api/errors/74c5385227477ffb.
Report an issue: GitHub.