-
Notifications
You must be signed in to change notification settings - Fork 166
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
rcl test test_publisher_init_fini
does not fini
#585
Comments
FYI: @eboasson |
That hash table stores refcounted "sertopic" objects and the RMW layer caches references to these in its publisher and subscription objects. The absence of They are only ever used for writing a serialized message, so there is something to be said for not caching them at all in the subscription, and cache in the publisher only if they serve a purpose. |
Don’t these sertopics need to be around for as long at the topic may be sent or received so they do have to be cached for at least the lifetime of the publisher/subscriber? |
@rotu, yes, but because they have to be around they are already managed by Cyclone: each topic entity carries a reference to the associated sertopic, ensuring they will remain in existence while there is still data. The refcounting of these things is to allow multiple DDS topic entities to share the same sertopic (this is what relies on those compare and hash functions where you found a few issues with calls to memcmp, &c.) The issue here is that for publishing serialised messages — All this does uncover a bug: the avoidance of duplicate sertopics in Cyclone works fine, but it means that following the Fixing this is easy, just use the sertopic that is actually used — but there is currently no way of getting that information … I suppose I will need to add a (trivial) function to retrieve it. E.g.: const struct ddsi_sertopic *dds_get_topic_sertopic(dds_entity_t topic); I think it'd be reasonable to make the return value a |
@rotu I've fixed the sertopic referencing issue, see the two PR references above. Cyclone now takes ownership of the sertopic and returns a pointer to rmw that can be safely used during the lifetime of the topic/writer. |
@dennis-adlink @rotu safe to close this issue? |
@claireyywang no, the test still doesn’t exercise the creation and destruction that it’s supposed to. It should. |
Also I’m still not clear whether this is a correct use of the rcl API (deleting a node with live publishers). If so, both use cases should be tested |
This part of Lines 156 to 157 in 0a795cc
The documentation suggests rcl/rcl/include/rcl/publisher.h Lines 564 to 565 in 0a795cc
The implementation of Lines 378 to 421 in 0a795cc
And Lines 219 to 222 in 0a795cc
In short it looks like the implementation expects another layer to handle the burden of destroying things in the right order. I'm not sure if I don't think the In short I think besides the test this is a documentation issue. I would recommend doing all of:
|
Since the test was fixed already, I'll close this issue and let the documentation PRs stand on their own. |
Thanks, @sloretz! |
I think the assumption was that if you fini the node, it would fini any "children" automatically, making any "dangling" pointers to those things, like a |
The tests in
test_publisher_init_fini
create a publisher (rcl_publisher_init
) without finalizing it (rcl_publisher_fini
). This causes a failed assertion in CycloneDDS in debug mode when tearing down the node (rcl_node_fini
), and possibly a memory leak. It's clear from the name of the test that the test was intended to have fini calls, but it's not clear whether or not RCL and/or CycloneDDS should issue a warning/error in this case.rcl/rcl/test/rcl/test_publisher.cpp
Lines 199 to 204 in 4b9c0a3
The text was updated successfully, but these errors were encountered: