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
Description
Presumably the interaction between the (newly introduced)
GenericSkeletonand an existing "normal" proxy (not aGenericProxy) seems to be broken.The root-cause is, that both sides (the
GenericSkeletonand the "normal" proxy) do interprete theEventDataStoragewithin the shared-memory differently/incompatible.Details:
In case of non-generic/typed skeletons the
EventDataStoragegets created within method-templatewhile in case of
GenericSkeleton/GenericSkeletonEventtzheEventDataStoragegets created within non-template methodIn the non-generic/typed approach, the
EventDataStoragegets created like this:This essentially creates a
DynamicArrayofelement_properties.number_of_slotsof typeSampleType.In the generic approach the
EventDataStoragegets created like this:These two representations are different/incompatible. The underlying raw-byte-array being the storage for the
DynamicArrayhas 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 ofstd::max_align_ttype - 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 keepDynamicArray<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 theDynamicArray<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-> replacingDynamicArray<T>with aDynamicArray<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