Skip to content
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

Crash when namespace is longer than topic name #155

Open
afrixs opened this issue Oct 3, 2023 · 1 comment
Open

Crash when namespace is longer than topic name #155

afrixs opened this issue Oct 3, 2023 · 1 comment

Comments

@afrixs
Copy link

afrixs commented Oct 3, 2023

ros-iron-image-transport-plugins version: 3.1.0-1jammy.20230908.194115

My node uses

image_transport::create_subscription(this, "input", [&](auto &msg) {}, "compressed", rmw_qos_profile_sensor_data);

When I run the node in a longer namespace, e.g. camera360, it crashes at this line

@sjgiewont
Copy link

I just ran into this same issue. As far as I'm aware the real issue is not due to the length of the namespace, but the namespace itself that is being referenced.

This section of code seems to be declaring the parameters for the image topics if they do not already exist. The problem is its trying to use the namespace of the subscriber node instead of the publisher node, which can be completely different! Ideally the namespace being referenced to determine ns_len (https://github.com/ros-perception/image_transport_plugins/blob/dd28c769bc22117ab32c15375b0c989bfb6d39a3/compressed_image_transport/src/compressed_subscriber.cpp#L79C10-L79C16) should be based on the namespace of base_topic, not the namespace of the current subscriber node. To my best knowledge this code was likely just copy pasted from the publisher source code, where using the node namespace is correct.

I was able to validate this quickly by changing my subscriber node namespace to match the namespace of the image topic being published. When i did this, the image transport was able to create the parameters correctly and there was no crash.

To ROS maintainers, what is the process for making this fix? Seems like this is an issue even in the latest rolling release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants