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

  1. Report the method/class to jadx with the full stack trace — this is an internal decompiler limitation.
  2. Use --decompilation-mode FALLBACK or set JadxArgs.decompilationMode to a simpler mode that avoids aggressive transformations.
  3. 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

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


AI-assisted analysis of skylot/jadx@e738a26571 (2026-08-14). Data as JSON: /api/errors/74c5385227477ffb. Report an issue: GitHub.