Fix start offset calculation in mmaped memory area

[RonFed]

This PR fixes a relatively rare bug that can happen when a write operation to the mmaped area is moving between pages. We didn't take the page-aligned address into account when updating the start offset.

[MrAlias]

Are there any tests we can add to prevent a regression?

[RonFed]

Are there any tests we can add to prevent a regression?

I think the e2e tests for grpc and http are covering the case of regression espicialy this part which checks the client-server propagation:

opentelemetry-go-instrumentation/internal/test/e2e/grpc/verify.bats

Lines 48 to 52 in f18c1b2

	@test "client, server :: server span has client span as parent" {
	server_parent_span_id=$(server_spans_from_scope_named ${SCOPE} | jq ".parentSpanId")
	client_span_id=$(client_spans_from_scope_named ${SCOPE} | jq ".spanId")
	assert_equal "$client_span_id" "$server_parent_span_id"
	}

The bug in this PR can happen approximately once every 50-100 client spans (since page size is 4096 bytes and we write ~40 bytes per request in gRPC for example)

[damemi]

The bug in this PR can happen approximately once every 50-100 client spans (since page size is 4096 bytes and we write ~40 bytes per request in gRPC for example)

1-2% of the time isn't insignificant, but I don't think any of our tests are set up for that kind of scenario. Maybe as part of #93 we should update the tests to send more than one span (ideally enough to cross the page threshold).

@RonFed just so I understand does this bug cause spans to get dropped by being overwritten in the map when the new address isn't taken into account?

[RonFed]

The bug in this PR can happen approximately once every 50-100 client spans (since page size is 4096 bytes and we write ~40 bytes per request in gRPC for example)

1-2% of the time isn't insignificant, but I don't think any of our tests are set up for that kind of scenario. Maybe as part of #93 we should update the tests to send more than one span (ideally enough to cross the page threshold).

@RonFed just so I understand does this bug cause spans to get dropped by being overwritten in the map when the new address isn't taken into account?

Right, it can cause spans to get dropped. Additionally in some case it caused invalid characters to override the trace parent header which resulted in a RST_STREAM code in the underlying http2 (in grpc).

[MrAlias]

@damemi thank you for updating #93. I'm going to merge this, and have the follow-up work tracked there.

[damemi]

btw @RonFed I missed it but I think this should have had a changelog entry. I'll add one in #737 for this.

Maybe we should define what needs a changelog entry somewhere?

[RonFed]

btw @RonFed I missed it but I think this should have had a changelog entry. I'll add one in #737 for this.

Maybe we should define what needs a changelog entry somewhere?

Ah thanks 🙂, yeah I don't really know when to add a changelog entry or not.