fako1024/slimcap

Sporadic test failure for mock source in no-drain mode

Closed this issue · 0 comments

On very rare occasions one of the tests for the ring buffer source fails (locally, never happened in a CI pipeline so far):

	=== RUN   TestClosedSourceNoDrain
		./github.com/fako1024/slimcap/capture/afpacket/afring/afring_mock_test.go:139:
				Error Trace:	./github.com/fako1024/slimcap/capture/afpacket/afring/afring_mock_test.go:139
				Error:      	Expected nil, but got: capture.Packet{0x3, 0xe, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x40, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x6, 0x0, 0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x15, 0xb3, 0x0, 0x50, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
				Test:       	TestClosedSourceNoDrain
	--- FAIL: TestClosedSourceNoDrain (0.03s)
	=== RUN   TestFillRingBuffer

This happens after closing the mock source, where of course we'd expect no further packets to arrive:

	// Close it right away
	require.Nil(t, mockSrc.Close())

	// Attempt to read from the source
	pkt, err := mockSrc.NextPacket(nil)
	require.Nil(t, pkt)

Most likely there is a bug / race somewhere in the Close() procedure that causes the source to still be open for a brief moment after it returns. Certainly not a critical issue (since it most likely only affects the mock source and doesn't really do any harm), but annoying still.