-
Notifications
You must be signed in to change notification settings - Fork 774
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sequences and Arrays of Nested Structs Cause Segfault on Pub-Sub for Dynamic Types (with minimal examples) #2969
Comments
methylDragon
changed the title
Sequences and Arrays of Nested Structs Cause Segfault on Pub-Sub for Dynamic Types
Sequences and Arrays of Nested Structs Cause Segfault on Pub-Sub for Dynamic Types (With minimal example)
Sep 22, 2022
methylDragon
changed the title
Sequences and Arrays of Nested Structs Cause Segfault on Pub-Sub for Dynamic Types (With minimal example)
Sequences and Arrays of Nested Structs Cause Segfault on Pub-Sub for Dynamic Types (With minimal examples)
Sep 22, 2022
methylDragon
changed the title
Sequences and Arrays of Nested Structs Cause Segfault on Pub-Sub for Dynamic Types (With minimal examples)
Sequences and Arrays of Nested Structs Cause Segfault on Pub-Sub for Dynamic Types (with minimal examples)
Sep 22, 2022
Just gonna ping @jparisu since they were engaging with a closely related problem in the listed issues |
clalancette
added a commit
to clalancette/Fast-RTPS
that referenced
this issue
Nov 11, 2022
It turns out that with the current XTypes code, attempting to create a sequence of nested structs ends up in a segfault. See eProsima#2969 for the details. After tracing through, it looks like what is happening is that there is some confusion on what should be registered as a "complete" type vs a "minimal" type, according to XTypes 1.3. In particular, what is happening is that the nested structure is being created as a complete type, but then when we go to look it up, we look it up as both a complete type and a minimal type. The former succeeds, and the latter fails, leading to the crash. This attempted fix just skips trying to look it up as a minimal type at all. This is probably not the correct fix, but it is unclear whether: 1. We should be "building" the type as both a complete and minimal one at build time, or 2. We should only look it up as either a complete or minimal I'm looking for feedback on which way to go here. Signed-off-by: Chris Lalancette <[email protected]>
31 tasks
1 task
I have opened a new issue explaining in detail the cause of the crash and its different manifestations in order to keep track in a single issue of the same bug. |
JLBuenoLopez
added
bug
Issue to report a bug
duplicate
and removed
triage
Issue pending classification
labels
Feb 14, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We just need a fix in-source (no need for a release yet) to do the demo. The trouble is, I think the issue is kinda inside the guts of FastDDS...
Is there an already existing issue for this?
They exist for earlier versions of FastDDS (2.3.X), it seems the issue still persists in the current version.
Expected behavior
TypeSupport
TypeSupport
Current behavior
TypeSupport
TypeSupport
<--- This segfaultsThis issue occurs for empty sequences, sequences, and arrays.
Steps to reproduce
I've prepared a minimal example:
https://github.com/methylDragon/fastdds-pr-minimal-examples
Once built, run:
The relevant code can be found here.
The types can be constructed, dynamic data can be created, and dynamic data is printable, it's just the registration of the type support that breaks for some reason.
Fast DDS version/commit
FastDDS 2.8.x: 78473a0
The examples workspace is using that specific SHA in the submodule, for convenience.
Platform/Architecture
Other. Please specify in Additional context section.
Transport layer
Default configuration, UDPv4 & SHM
Additional context
This bug is hampering the progress of the dynamic types and type introspection reference implementation for ROS 2 as proposed in REP 2011, to be presented in ROSCon 2022. Fixing it will expedite the progress for completing the demo before the talk.
Without the bug being fixed, a vast majority of use cases in ROS 2 will not be possible (sequences of nested message types.) So this is quite critical.
This is on 22.04, but I don't think the platform matters in this case.
I've done some tracing, the segfault occurs in both of these lines: here and here.
I don't know why it occurs. Though I suspect it's similar to these issues:
XML configuration file
No response
Relevant log output
The text was updated successfully, but these errors were encountered: