skylot/jadx · error · JadxRuntimeException
Expected to find block info within {}
Error message
Expected to find block info within {} What it means
Thrown by BaseBlockTraverserHandler.handle() when the current TraverserState's getBlockInsnInfo() returns null. The finally-block traverser subsystem requires every block-level handler state to carry a TraverserBlockInfo (the active block and its instruction offsets). A null value means the state type does not track an active block (e.g. a terminal, global, or cache-recovery state was incorrectly routed to this handler). This is an internal invariant violation in jadx's 'finaly' (finally-extraction) visitor pipeline, not a user-configuration error.
Source
Thrown at jadx-core/src/main/java/jadx/core/dex/visitors/finaly/traverser/handlers/BaseBlockTraverserHandler.java:27
import jadx.core.dex.visitors.finaly.traverser.visitors.ImplicitInsnBlockTraverserVisitor;
import jadx.core.dex.visitors.finaly.traverser.visitors.PathEndBlockTraverserVisitor;
import jadx.core.utils.exceptions.JadxRuntimeException;
public class BaseBlockTraverserHandler extends AbstractBlockPathTraverserHandler {
public BaseBlockTraverserHandler(TraverserState initialState) {
super(initialState);
}
public BaseBlockTraverserHandler(AtomicReference<TraverserState> initialStateRef) {
super(initialStateRef);
}
@Override
protected void handle() {
TraverserBlockInfo blockInsnInfo = getState().getBlockInsnInfo();
if (blockInsnInfo == null) {
throw new JadxRuntimeException("Expected to find block info within " + getClass().getSimpleName());
}
TraverserActivePathState comparator = getState().getComparatorState();
AtomicReference<TraverserState> stateRef = comparator.getReferenceForState(getState());
if (stateRef == null) {
throw new JadxRuntimeException("Orphaned traverser state");
}
BlockNode block = blockInsnInfo.getBlock();
ImplicitInsnBlockTraverserVisitor implicitVisitor = new ImplicitInsnBlockTraverserVisitor(getState());
TraverserState stateAfterImplicit = implicitVisitor.visit(block);
PathEndBlockTraverserVisitor pathEndVisitor = new PathEndBlockTraverserVisitor(stateAfterImplicit);
TraverserState nextState = pathEndVisitor.visit(block);
stateRef.set(nextState);
}
}
View on GitHub (pinned to e738a26571)
Solutions
- Report the issue to the jadx project with the input file and full stack trace — this is an internal decompiler bug in the finally visitor.
- As a workaround, disable finally extraction by passing the decompiler argument to skip the finally pass (e.g. --no-debug-info or relevant visitor skip flags) and re-run.
- Try a different jadx version — the finally traverser is under active development and the edge case may be fixed in a newer release.
- If developing jadx itself, add a null check and inspect which concrete TraverserState subclass is being dispatched to a block handler; the state's getNextHandler() is returning the wrong handler type.
Defensive patterns
Strategy: validation
Validate before calling
// Before dispatching a state to a block handler, verify it carries block info
TraverserBlockInfo info = state.getBlockInsnInfo();
if (info == null) {
// Skip or route to a non-block handler instead of throwing
return;
} Prevention
- This is an internal jadx invariant; end users cannot guard against it at the API level.
- Keep jadx updated — the finally traverser is under active development.
- If developing jadx, never route non-block TraverserState types (terminal, global, cache) to BaseBlockTraverserHandler.
When it happens
Trigger: A TraverserState subclass whose getUnderlyingBlockInsnInfo() returns null (such as TerminalTraverserState, a global source state, or a cache-recovery wrapper) is passed into a BaseBlockTraverserHandler via the traverser controller's getNextHandler() dispatch. This happens when a state transition produces a non-block state but the controller still routes it to a block-handling handler.
Common situations: Decompiling an APK/JAR that contains complex or unusual try-finally control flow that the finally-extraction algorithm does not handle. Rarely triggered on typical inputs; almost always indicates a logic gap in the finally visitor for a specific bytecode shape (e.g. nested finally blocks, finally blocks with exception handlers, or synthetic compiler-generated control flow).
Related errors
- Unknown global traverser state. Has a global state been dupl
- Orphaned TraverserState node
- Orphaned traverser state
- Orphaned traverser state
- Attempted to get instructions slice of block {} with {} skip
AI-assisted analysis of skylot/jadx@e738a26571 (2026-08-14).
Data as JSON: /api/errors/80edcc3d9d471233.
Report an issue: GitHub.