cilium/cilium · error

computing blocks: %w

Error message

computing blocks: %w

What it means

MakeBlocks computes basic blocks from a BPF instruction stream, first trying a cached result (loadBlocks) and otherwise computing via computeBlocks. This error wraps any failure from computeBlocks, so the underlying cause is one of its sub-steps (markBranches, allocateBlocks, connectBlocks). It indicates the instruction stream could not be analyzed, usually because it is malformed or contains unresolvable jumps.

Source

Thrown at pkg/bpf/analyze/blocks.go:644

// MakeBlocks returns a list of basic blocks of instructions that are always
// executed together. Multiple calls on the same insns will return the same
// Blocks object.
//
// Blocks are created by finding branches and jump targets in the given insns
// and cutting up the instruction stream accordingly.
func MakeBlocks(insns asm.Instructions) (Blocks, error) {
	if len(insns) == 0 {
		return nil, errors.New("insns is empty, cannot compute blocks")
	}

	if blocks := loadBlocks(insns); blocks != nil {
		return blocks, nil
	}

	blocks, err := computeBlocks(insns)
	if err != nil {
		return nil, fmt.Errorf("computing blocks: %w", err)
	}

	if err := storeBlocks(insns, blocks); err != nil {
		return nil, fmt.Errorf("storing blocks: %w", err)
	}

	return blocks, nil
}

// computeBlocks computes the basic blocks from the given instruction stream.
func computeBlocks(insns asm.Instructions) (Blocks, error) {
	if err := markBranches(insns); err != nil {
		return nil, fmt.Errorf("marking branches: %w", err)
	}

	blocks, callers, err := allocateBlocks(insns)
	if err != nil {
		return nil, fmt.Errorf("allocating blocks: %w", err)

View on GitHub (pinned to ac7b90affa)

Solutions

1. Inspect the wrapped %w error to identify the failing phase (marking branches, allocating, connecting)
2. Ensure the instructions were produced by asm.Assemble or fully initialized (all references resolved, offsets assigned) before analysis
3. Validate jump targets are within the instruction stream
4. If loading cached blocks may be stale, clear the cache so computeBlocks runs on a known-good stream

Example fix

// before
blocks, err := MakeBlocks(insns) // opaque 'computing blocks: ...'
// after
if err := insns.Iterate(func(){}); err == nil {
    _ = insns // ensure program assembled: asm.Assemble returned no error earlier
}
blocks, err := MakeBlocks(insns)
if err != nil {
    return fmt.Errorf("MakeBlocks on %d insns: %w", len(insns), err)
}

if len(insns) == 0 {
    return errors.New("empty instruction stream")
}

blocks, err := MakeBlocks(insns)
if err != nil {
    var unwrapped error = err
    for errors.Unwrap(unwrapped) != nil { unwrapped = errors.Unwrap(unwrapped) }
    return fmt.Errorf("MakeBlocks failed (%v): %w", unwrapped, err)
}

When it happens

Trigger: Calling MakeBlocks (directly or via analyzers/tests) on an asm.Instructions stream whose branches are malformed, whose jumps reference invalid offsets, or whose block graph cannot be wired (e.g. jump target outside the program).

Common situations: Loading hand-assembled or patched BPF instructions, programs built dynamically where a branch offset was computed wrong, or instructions that were not fully assembled/renumbered before analysis.

Related errors

• allocating blocks: %w
• storing blocks: %w
• marking branches: %w
• connecting blocks: %w
• determine jump target instruction offset: %w

AI-assisted analysis of cilium/cilium@ac7b90affa (2026-08-31). Data as JSON: /api/errors/0cab07c4eb794d21. Report an issue: GitHub.