Memory leak: Syscall events never release eBPF data

[matthyx]

Summary

Syscall events never call Release() on their eBPF data, causing a memory leak.

Details

In pkg/containerwatcher/v2/container_watcher.go:162-163, syscall events are explicitly skipped from the Release() call:

if enrichedEvent.Event.GetEventType() != utils.SyscallEventType {
    enrichedEvent.Event.Release() // at this time we should not need the event anymore
}

This was intentional because the syscall tracer (in pkg/containerwatcher/v2/tracers/syscall.go:125-138) creates multiple DatasourceEvents that share the same underlying eBPF Data pointer:

func (st *SyscallTracer) callback(event *utils.DatasourceEvent) {
    syscallsBuffer := event.GetSyscalls()
    for _, syscall := range decodeSyscalls(syscallsBuffer) {
        st.eventCallback(&utils.DatasourceEvent{
            Data:       event.Data, // WARNING we pass the original data here, not a DeepCopy
            Datasource: event.Datasource,
            EventType:  event.EventType,
            Syscall:    syscall,
        }, containerID, processID)
    }
}

The comment on line 32 explicitly warns: "WARNING we pass the original data here, not a DeepCopy"

The intent was to avoid calling Release() on one sub-event and freeing data for all sibling events. However, this means the copied eBPF data created at line 112 IS NEVER RELEASED, causing a leak.

Call Chain

1. syscall.go:112 - Initial copy: source.DeepCopy(data) (never released)
2. syscall.go:132 - Shared across sub-events: Data: event.Data
3. container_watcher.go:162 - Release skipped for ALL syscall events
4. Memory leaks for every syscall capture

Potential Solutions

1. Deep copy each sub-event (simplest, cleanest)

   • In syscall callback: Data: source.DeepCopy(event.Data),
   • Remove the skip check at container_watcher.go:162
   • Pro: Each event independently owned, consistent with other tracers
   • Con: Some memory overhead

2. Add reference counting

   • Track number of sub-events sharing each Data pointer
   • Release when count reaches zero
   • Pro: Shared memory preserved
   • Con: More complex, error-prone

3. Release in syscall callback

   • After syscall loop, call event.Datasource.Release(event.Data)
   • Pro: Simple, contained in tracer
   • Con: Still violates the "1:1 Release after processing" pattern

Recommendation: Option 1 — it makes each event independently owned like other tracer types, avoiding shared-data complexity.

[yugal07]

I think option 1 sounds good, There is some memory overhead but the current code already leaks the entire copy forever, its unbounded memory growth that never stops.
I would like to work on this. Can you please assign it to me? @matthyx