golabels: ignore attach when Go plugins are loaded

[gnurizen]

When a Go process loads shared libraries via plugin.Open(), the profiler creates separate golabels interpreter instances for each Go ELF file in the process. Since Go plugins must be built with the same Go version as the host binary and share the runtime, they produce identical GoLabelsOffsets — but both instances write and delete the same PID-keyed eBPF map entry.

The second Detach call fails with "key does not exist" because the first instance already removed it.

This fixes the issue by ignoring the attach of Go plugins, since the proc data would be the same there's no point in maintaining a golabels instance for it.

Fixes #1301

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: gnurizen / name: Tommy Reilly (07d594b, 760c733, b00ef1f)

[rogercoll]

Thanks! Maybe add a debug log line if something actually goes wrong with golabels in a multi-plugin process?

[florianl]

This would also incorporate #1314 (comment):

Suggested change

	if err := ebpf.DeleteProcData(libpf.GoLabels, pid); err != nil && !errors.Is(err, cebpf.ErrKeyNotExist) {
	return err
	}
	return nil
	err := ebpf.DeleteProcData(libpf.GoLabels, pid)
	switch {
	case err == nil: return
	case errors.Is(err, cebpf.ErrKeyNotExist):
	log.Debugf("Entry for PID %d already removed", pid)
	return nil
	default:
	return err
	}

[gnurizen]

Don't need the err == nil case I think, I pushed a commit to add logging.

[christos68k]

LGTM

[christos68k]

It it worth further clarifying that Go does not support unloading plugins here? If one doesn't know that then one could think that we still have an issue.

[gnurizen]

I completely flipped this on its head and think its better to just ignore Go plugins, please take another look, thanks!

[christos68k]

Thanks!