go-delve/delve · warning

chan type not yet supported by ebpf tracing

Error message

chan type not yet supported by ebpf tracing

What it means

Same fallback path as the map case: when the eBPF argument map provides only a reflect.Kind and the kind is Chan, synthesizeTypeFromKind marks the parameter Unreadable because channel internals cannot be reconstructed from the 0x30 raw bytes captured by the uprobe. The trace event is not lost; only this channel-typed argument is undisplayable.

Source

Thrown at pkg/proc/internal/ebpf/helpers.go:567

		iparam.RealType = &godwarf.UintType{BasicType: godwarf.BasicType{CommonType: godwarf.CommonType{ByteSize: vs, ReflectKind: reflect.Uintptr}}}
	case reflect.Slice:
		iparam.Kind = reflect.Uintptr
		iparam.RealType = &godwarf.UintType{BasicType: godwarf.BasicType{CommonType: godwarf.CommonType{ByteSize: 8, ReflectKind: reflect.Uintptr}}}
	case reflect.String:
		if len(iparam.Data) >= 16 {
			iparam.Base = fakeAddressUnresolv + uint64(valSize)
			iparam.Len = int64(binary.LittleEndian.Uint64(iparam.Data[8:16]))
		}
		iparam.RealType = &godwarf.StringType{
			StructType: godwarf.StructType{
				CommonType: godwarf.CommonType{ByteSize: 16, ReflectKind: reflect.String},
				Kind:       "struct",
			},
		}
	case reflect.Map:
		iparam.Unreadable = fmt.Errorf("map type not yet supported by ebpf tracing")
	case reflect.Chan:
		iparam.Unreadable = fmt.Errorf("chan type not yet supported by ebpf tracing")
	case reflect.Interface:
		iparam.Unreadable = fmt.Errorf("interface type not yet supported by ebpf tracing")
	case reflect.Func:
		iparam.Unreadable = fmt.Errorf("func type not yet supported by ebpf tracing")
	case reflect.Struct:
		iparam.Unreadable = fmt.Errorf("struct type not yet supported by ebpf tracing without DWARF type")
	case reflect.Array:
		iparam.Unreadable = fmt.Errorf("array type not yet supported by ebpf tracing without DWARF type")
	default:
		iparam.Unreadable = fmt.Errorf("unrecognized reflect.Kind %d from eBPF", iparam.Kind)
	}
}

func createFunctionParameterList(entry uint64, goidOffset int64, args []UProbeArgMap, isret bool) function_parameter_list_t {
	var params function_parameter_list_t
	params.goid_offset = uint32(goidOffset)
	params.fn_addr = entry
	params.is_ret = isret

View on GitHub (pinned to a23773e6c3)

Solutions

  1. Do not attach eBPF tracepoints to functions whose arguments are channels; trace a scalar-returning wrapper instead.
  2. Keep DWARF info in the traced binary so the full channel element type resolution path can be attempted instead of the Kind-only fallback.
  3. Treat the parameter as unreadable in tooling: check iparam.Unreadable before loading the value.
  4. Watch delve's eBPF type-support roadmap for chan support.

Example fix

// before
dlv trace --ebpf worker.Send   // Send(ch chan Job)
// parameter shows: chan type not yet supported by ebpf tracing
// after
// trace with a pointer/scalar-friendly signature:
func (w *Worker) SendID(id int) { w.send(jobs[id]) }
dlv trace --ebpf worker.SendID
Defensive patterns

Strategy: type-guard

Validate before calling

// Reject chan-typed arguments before creating the tracepoint:
func argSupportsEBPF(t godwarf.Type) bool {
	return t != nil && t.Common().ReflectKind != reflect.Chan
}

Type guard

func isChanParam(p *RawUProbeParam) bool {
	return p != nil && p.Kind == reflect.Chan
}

Try / catch

if p.Unreadable != nil && strings.Contains(p.Unreadable.Error(), "chan type not yet supported") {
	log.Printf("skipping chan parameter %s (eBPF unsupported)", p.Name)
	continue
}

Prevention

When it happens

Trigger: Tracing a function with a chan-typed parameter or return value via the eBPF backend when no DWARF type is available for the argument, so handleParamEvent falls back to synthesizeTypeFromKind and hits 'case reflect.Chan'.

Common situations: 'dlv trace --ebpf' on producer/consumer functions taking channels; eBPF type tests against fixtures with chan parameters; tracing functions in binaries with insufficient DWARF info.

Related errors

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