go-delve/delve · error

could not find module data for type %s

Error message

could not find module data for type %s

What it means

dwarfToRuntimeType maps a DWARF type to its Go runtime.reflect_type representation by locating the module data (runtime.moduledata) of the shared object that defines the type. When bi.imageToModuleData cannot find module data matching the type's shared object, the runtime type address cannot be computed (md.types + off) and this error is thrown. It indicates Delve could not correlate the binary's compile unit with a parsed runtime.moduledata.

Source

Thrown at pkg/proc/types.go:162

	if err != nil {
		return 0, false, false, err
	}
	off, ok := e.Val(godwarf.AttrGoRuntimeType).(uint64)
	if !ok {
		return 0, false, false, nil
	}

	mds, err := bi.getModuleData(mem)
	if err != nil {
		return 0, false, false, err
	}

	md := bi.imageToModuleData(so, mds)
	if md == nil {
		if so.index > 0 {
			return 0, false, false, fmt.Errorf("could not find module data for type %s (shared object: %q)", typ, so.Path)
		} else {
			return 0, false, false, fmt.Errorf("could not find module data for type %s", typ)
		}
	}

	typeAddr = md.types + off

	rtyp, err := bi.findType(bi.runtimeTypeTypename())
	if err != nil {
		return 0, false, false, err
	}
	_type := newVariable("", typeAddr, rtyp, bi, mem)

	return typeAddr, getRuntimeTypeDirect(_type), true, nil
}

// getRuntimeTypeDirect returns a bool that says if the type in _type can be stored directly into an interface variable.
func getRuntimeTypeDirect(_type *Variable) bool {
	// Go 1.26 and beyond have this flag in the TFlag field.
	// Go 1.25 and earlier have this flag in the Kind field.

View on GitHub (pinned to a23773e6c3)

Solutions

1. Rebuild the program as a single static Go binary (avoid -buildmode=plugin/shared) if runtime type conversion of those types is needed.
2. Ensure the binary on disk matches the running process exactly (same build, not stripped); re-attach after rebuilding.
3. Check Delve version support for plugins/shared libraries and upgrade Delve.
4. As a workaround, avoid operations requiring runtime type conversion (interface conversion/comparison of those types) in the debugger.

Example fix

// before: debugging a plugin type via eval
dlv exec ./app -- eval ifaceVal

// after: rebuild statically and re-debug
go build -o app ./cmd/app
dlv exec ./app -- eval ifaceVal

// Verify the target uses no plugin/shared-library objects before evaluating types
state, err := client.GetState()
if err != nil { return err }
// If your program uses -buildmode=plugin or cgo shared libs, expect runtime-type
// conversions on those objects to fail; avoid such evals or rebuild statically.

// rpc2 client
_, err := client.EvalVariable(scope, expr, cfg)
if err != nil && strings.Contains(err.Error(), "could not find module data for type") {
    // fall back to non-runtime-type operations or rebuild statically
}

When it happens

Trigger: Calling ConvertEvalScope/evaluate on a variable whose type lives in a shared library or plugin, so executeOp/convertToEface call dwarfToRuntimeType and imageToModuleData returns nil for that shared object (so.index > 0 gives the variant with the so path).

Common situations: Debugging Go binaries using cgo shared libraries or -buildmode=plugin; attaching to processes where shared objects were loaded after attach and moduledata scan was stale; stripped or non-Go-built shared objects lacking Go moduledata; mismatched binary on disk vs running process.

Related errors

• unable to find function context
• unable to find locals: no debug information present in binar
• malformed map type: buckets, oldbuckets or overflow field no
• ctx variable not found
• ep variable not found

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