Generic skeleton integration test

[ShoroukRamzy]

Overview

This PR significantly expands the integration testing suite by introducing tests for both Generic-Typed (type-erased Skeleton Provider with Strongly-Typed Proxy Consumer) and Generic-Generic (type-erased Skeleton Provider with type-erased Proxy Consumer) interactions.

This addresses this issue #261 and #311 by rigorously validating the underlying shared memory (SHM) communication mechanisms with various payload sizes (64, 32, 16, and 8 bytes) and configurations.

The tests strictly evaluate type-erased memory striding, boundary enforcements, and data integrity by spinning up a provider that sends 30 consecutive samples into a heavily constrained 5-slot ring buffer, forcing multiple buffer wrap-arounds.

Test Scope & Root Causes of Current Failures

Currently, all introduced test variants intentionally fail, successfully exposing critical bugs within the Generic skeleton implementation related to shared memory allocation and addressing. The failure modes depend on the payload size relative to std::max_align_t (which is assumed to be 32 bytes on the current architecture).

The identified root causes for these failures are:

1. Data Corruption (Expected: X, got: 0 or Y)

Affected Tests: All Generic-Generic interaction tests (64, 32, 8-byte payloads) and Generic-Typed tests with payloads > std::max_align_t (64-byte, 32-byte payloads).
Root Cause: The fundamental issue was an incorrect base pointer being returned for event data. The SkeletonMemoryManager::CreateGenericEventDataInCreatedSharedMemory and Skeleton::RegisterGeneric functions were erroneously returning a pointer to the EventDataStorage object itself, instead of the actual data buffer managed within that object (EventDataStorage::data()). This led both providers and consumers to miscalculate offsets, resulting in writes to unintended (often zero-initialized) memory locations and reads from those incorrect, zero-filled locations.

2. Boundary Check Crashes (Exit Code 134 - SIGABRT)

Affected Tests: Generic-Typed interaction tests with payloads < std::max_align_t (16-byte, 8-byte payloads).
Root Cause: This failure was caused by an incorrect capacity calculation for the shared memory array. The EventDataStorage's internal DynamicArray was being initialized with a capacity based on num_max_align_elements. For smaller payloads, this calculated capacity was often less than the numberOfSampleSlots specified in the configuration. When the consumer attempted to retrieve one beyond this physically undersized capacity, it resulted in out-of-bounds memory access, triggering assertions and process crashes.

[ShoroukRamzy]

Hi @crimson11,
I will confirm the main reasons for the above two issues soon.

[ShoroukRamzy]

Hi @crimson11, I will confirm the main reasons for the above two issues soon.

@crimson11, Done

[crimson11]

I will have a look at it tomorrow!

[crimson11]

@ShoroukRamzy
I had now a 1st look. I do have the following question:
To me it is unexpected, that the Generic-Generic interaction fails?
Because what you have written above:

The fundamental issue was an incorrect base pointer being returned for event data. The SkeletonMemoryManager::CreateGenericEventDataInCreatedSharedMemory and Skeleton::RegisterGeneric functions were erroneously returning a pointer to the EventDataStorage object itself, ...

should have no effect in this case. Because a typed proxy/proxy event uses the DataStoragePointer here: https://github.com/eclipse-score/communication/blob/main/score/mw/com/impl/bindings/lola/generic_proxy_event.cpp#L156 , which the GenericSkeleton has placed into the events_metainfo_ here:
https://github.com/eclipse-score/communication/blob/main/score/mw/com/impl/bindings/lola/skeleton_memory_manager.cpp#L228
... and this is the "correct" raw-data-storage pointer (without the enclosing DynamicArray control structure).
So imho the Generic-Generic interaction should work, because:

• the GenericSkeleton/provider is storing the raw-pointer (not the pointer to a DynamicArray) into the "meta-info-map"
• the GenericProxyEvent/consumer is getting this raw-.pointer from the "meta-info-map"

Am I missing something here? I did not yet re-run/use your tests as picking it from the fork is "tedious" ;)