Skip to content

Bug: GenericSkeleton interaction with typed Proxies not working #311

@crimson11

Description

@crimson11

Description

Presumably the interaction between the (newly introduced) GenericSkeleton and an existing "normal" proxy (not a GenericProxy) seems to be broken.
The root-cause is, that both sides (the GenericSkeleton and the "normal" proxy) do interprete the EventDataStorage within the shared-memory differently/incompatible.

Details:
In case of non-generic/typed skeletons the EventDataStorage gets created within method-template

template <typename SampleType>
SkeletonMemoryManager::CreateEventDataFromOpenedSharedMemory(const ElementFqId element_fq_id,
                                                                  const SkeletonEventProperties& element_properties)

while in case of GenericSkeleton/GenericSkeletonEvent tzhe EventDataStorage gets created within non-template method

CreateEventDataFromOpenedSharedMemory(
        const ElementFqId element_fq_id,
        const SkeletonEventProperties& element_properties,
        size_t sample_size,
        size_t sample_alignment)

In the non-generic/typed approach, the EventDataStorage gets created like this:

auto* typed_event_data_storage_ptr = storage_resource_->construct<EventDataStorage<SampleType>>(
        element_properties.number_of_slots,
        memory::shared::PolymorphicOffsetPtrAllocator<SampleType>(*storage_resource_));

This essentially creates a DynamicArray of element_properties.number_of_slots of type SampleType.

In the generic approach the EventDataStorage gets created like this:

auto* data_storage = storage_resource_->construct<EventDataStorage<std::max_align_t>>(
        num_max_align_elements, memory::shared::PolymorphicOffsetPtrAllocator<std::max_align_t>(*storage_resource_));

These two representations are different/incompatible. The underlying raw-byte-array being the storage for the DynamicArray has the same size.
Nowever the type T is differtent, which is reflected in the size/number_of_elements member variable in the DynamicArray! I.e. in the case of the generic skeleton/skeleton event, the number of elements gets calculated on the basis of std::max_align_t type - which typically is much smaller than the real type used in case of typed skeletons (and proxies), thus leading to a much larger calculated number of elements (num_max_align_elements).

The problem is the underlying usage of DynamicArray<T> here and its existing/restricted ctors. If we would like to keep DynamicArray<T>, we would (for the generic case) need a ctor, which takes the number of slots (the real number of slots of T as from the config) plus a pointer to pre-allocated storage! I.e. in the generic case, we would NOT let the DynamicArray<T> allocate/calculate the underlying memory as this would happen based on T, which we don't have.
Or we could generally get rid of a "typed" EventDataStorage -> replacing DynamicArray<T> with a DynamicArray<std::byte> and always (in the typed and generic case) do a slot access based on "pointer arithmetic" with simply the knowledge about sizeof(SampleType)/alignof(SampleType).

Error Occurrence Rate

None

How to reproduce

Will be shown in #261

Supporting Information

No response

Classification

major

Affected Version

0.5

Expected Closure Version

1.0

Category

  • Safety Related
  • Security Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions