Conversation
Build failure seems unrelated? |
Signed-off-by: Tim Clephas <tim.clephas@nobleo.nl>
|
|
|
@ros-pull-request-builder retest this please |
|
Thank you, fails on the same error. It seems like the main branch is also failing for half a year already. Probably because the github actions use |
I opened the PR #398 to fix it, just waiting for review. But yeah, I think the problem is using |
| topic_name.c_str(), bridge.ros1_type_name.c_str(), bridge.ros2_type_name.c_str(), e.what()); | ||
| if (std::string(e.what()).find("No template specialization") != std::string::npos) { | ||
| fprintf(stderr, "check the list of supported pairs with the `--print-pairs` option\n"); | ||
| static std::set<std::string> logged_topic_errors; |
There was a problem hiding this comment.
having this static global variable is safe since both ros1 and ros2 uses single thread to poll the process.
| auto entry = logged_topic_errors.emplace(topic_name); | ||
| if (entry.second) { // topic name was not already in the set, so log once |
There was a problem hiding this comment.
if create -> remove -> create case on the same topic name, this will never print the error on 2nd trial since the element will never be pulled out when the topic becomes unavailable.
besides, this just increase the element in this global space as long as this process is running, could be memory leak problem.
There was a problem hiding this comment.
if create -> remove -> create case on the same topic name, this will never print the error on 2nd trial since the element will never be pulled out when the topic becomes unavailable.
This was not meant to be supported. Since publishers can be created on demand (actually are a lot in our case). Topics become available and unavailable more often.
could be memory leak problem.
Yes, technically. But the memory will be limited by the amount of unique topics which fail. Which I assume have a limit.
I tried keeping the solution locally to the logging statement. Same kind of implementation that ROS_INFO_ONCE uses with the static variable.
Let me know if you would like a solution which is kept in sync with the publishers and subscribers. In which case the administration will probably passed up and down through functions.
|
works great, thanks for the PR |
5 participants
Most topics will keep existing. So getting this log message every second is not helpful.