go-delve/delve · error

disassemble failed with error %w

Error message

disassemble failed with error %w

What it means

Wrapped error from Debugger.traverse when proc.Disassemble cannot decode the instruction range [f.Entry, f.End) of a function being walked during follow-calls traversal. Disassembly is required to enumerate the call instructions of each function in the call graph; if the memory cannot be read or an instruction cannot be decoded, traversal aborts. The original disassembler error is preserved via %w.

Source

Thrown at service/debugger/debugger.go:1455

		if parent.Depth > followCalls {
			continue
		}
		if !parent.visited {
			funcs = append(funcs, parent.Func.Name)
			parent.visited = true
		} else if parent.visited {
			continue
		}

		if parent.Depth+1 > followCalls {
			// Avoid diassembling if we already cross the follow-calls depth
			continue
		}
		f := parent.Func
		text, err := proc.Disassemble(t.Memory(), nil, t.Breakpoints(), t.BinInfo(), f.Entry, f.End)

		if err != nil {
			return nil, fmt.Errorf("disassemble failed with error %w", err)
		}
		for _, instr := range text {
			// Dynamic functions need to be handled specially as their destination location
			// is not known statically, hence its required to put a breakpoint in order to
			// acquire the address of the function at runtime and we do this via a
			// call back mechanism
			if instr.IsCall() && instr.DestLoc == nil {
				dynbp, err := t.SetBreakpoint(0, instr.Loc.PC, proc.NextBreakpoint, nil)
				if err != nil {
					return nil, fmt.Errorf("error setting breakpoint inside deferreturn")
				}
				dynCallback := func(th proc.Thread, tgt *proc.Target) (bool, error) {
					// TODO(optimization): Consider using an iterator to avoid materializing
					// the full stack when we only need frames up to the root function
					rawlocs, err := proc.ThreadStacktrace(tgt, tgt.CurrentThread(), followCalls+2)
					if err != nil {
						return false, fmt.Errorf("thread stack trace returned error")
					}

View on GitHub (pinned to a23773e6c3)

Solutions

1. Inspect the wrapped %w error for the exact PC/decode failure.
2. Exclude the problematic function from the filter regex (e.g. narrow `main\.` instead of `\.`).
3. Use a smaller followCalls so fewer functions are disassembled.
4. Ensure the target memory is readable (process alive, core dump complete with all PT_LOAD segments).
5. Confirm the binary/architecture is supported by Delve (dlv backend support list).

Example fix

// before
funcs, err := client.Functions("main|runtime|internal/poll", 10)
// after
funcs, err := client.Functions("main", 3) // exclude runtime/asm-heavy packages

// ensure the target is alive and the backend can read memory before follow-calls
state, err := client.GetState()
if err != nil || state.Exited {
    return fmt.Errorf("target not traceable: %v", err)
}

var disasmErr *proc.ErrUnknownInstruction // or check wrapped cause
if errors.As(err, &disasmErr) {
    log.Printf("undecodable instruction at %#x", disasmErr.PC)
}

funcs, err := client.Functions(filter, followCalls)
if err != nil && strings.Contains(err.Error(), "disassemble failed") {
    // retry without deep traversal
    funcs, err = client.Functions(filter, 0)
}

When it happens

Trigger: During Debugger.Functions(filter, followCalls>0): a matched function's body spans unreadable or non-executable memory (e.g. dynamically generated code, unmapped page in a core dump), or the backend's Memory() read fails mid-range, or the disassembler encounters bytes it cannot decode for the target architecture.

Common situations: Analyzing core dumps where the text page is not mapped; debugging stripped/obfuscated binaries with data embedded in text; JIT or assembly-heavy functions; architectures where golang.org/x/arch has partial coverage; remote/gdbserial targets with restricted memory reads.

Related errors

• failed to disassemble instruction: %w
• couldn't read pointer: %w
• could not dereference %s: %v
• could not read context: %v
• parent pointer unreadable: %w

AI-assisted analysis of go-delve/delve@a23773e6c3 (2026-08-31). Data as JSON: /api/errors/71fb52695d45b070. Report an issue: GitHub.