Exception being thrown: failed to initialize rcl node: Logger already initialized for node #375
Comments
|
Adding @crdelsey |
|
@mkhansen-intel does the error happen with a different node name like |
|
Good idea, but I just tried it and it didn't make a difference except in the logger output on the screen: |
|
OK here's more info. The gdb backtrace of the error is this: Line 19 is where it calls into the TransformListener constructor. I still don't understand why that is causing an exception to be thrown. Is the bug in TransformListener? Maybe I should have filed the bug in Geometry2 instead? Let me know how I should proceed. |
|
Interesting. When you specify the I created a minimal example to reproduce the problem. #include "rclcpp/rclcpp.hpp"
using namespace std;
int main(int argc, char ** argv)
{
rclcpp::init(argc, argv);
auto node1 = rclcpp::Node::make_shared("foo");
auto node2 = rclcpp::Node::make_shared("bar");
// rclcpp::spin(node);
rclcpp::shutdown();
return 0;
}If I build the code above into a node called |
|
@crdelsey In that example the nodes can be given different names by prefixing the rule with original name |
|
@sloretz That does fix the problem in my example. However, I'm not aware of a way to specify those prefixes when using a launch file like in the original problem description. |
|
Why does the logger now need to throw that exception? What harm is it causing to have two nodes with the same logger? If the only downside is that they both will log using the same name and therefore you won't know what output was from which node, then it seems like a warning "Duplicate logger for node abc" is all that is needed. Am I missing something? |
I agree two nodes sharing a logger would be fine as a warning. Elsewhere, nodes with the same name create parameter services with the same name. This makes setting different parameters on them a problem. |
ghost
mentioned this issue
|
So @crdelsey has a work-around for this which we can live with. I still think this exception should be a warning instead. Please let me know whether that change will be made so we can revert the work-around at a future date. |
|
I can reproduce this exception with but not with I don't yet know why this is the case. |
|
Another way to work around the issue is to use another But I assume in this case |
|
Here are a few options. @ros2/team mind looking at the options and giving feedback?
|
|
@sloretz so, given that those hidden nodes seem to work only as proxies/wrappers to ROS interfaces, I'd say (5) is a reasonable path forward, though a less obscure exception would be nice i.e. letting you know there're other non-anonymous nodes in the process and thus you can't just use BTW what would happen if e.g. two |
Yup, two TransformListener alone crashes since they create nodes with the same name#include "tf2_ros/transform_listener.h"
#include "rclcpp/rclcpp.hpp"
int main(int argc, char ** argv)
{
rclcpp::init(argc, argv);
auto nh = rclcpp::Node::make_shared("dual_listener");
auto clock = nh->get_clock();
tf2_ros::Buffer buffer1(clock);
auto tfl1 = tf2_ros::TransformListener(buffer1);
tf2_ros::Buffer buffer2(clock);
auto tfl2 = tf2_ros::TransformListener(buffer2);
return 0;
} |
|
I agree that (5) seems like the right thing to do (and then do the TODO to resolve this particular ticket). I may have been under the wrong assumption, but I thought fully qualified node names should be unique. If so, then I believe an error (rather than a warning) is correct in the reported case. |
|
So we currently run into this issue as well on rosbag2.
|
A little background, for the rosout logging functionality in ROS2 we create a publisher instance on every node and the logger that is associated with that node sends logs out on the rosout topic publisher specifically for that node. We did it this way to avoid randomly picking a single node in the process and sending all logs out via a publisher on that node. Additionally, the only thing linking a node logger in rclcpp/rclpy to the logger in the rcl layer is a string name that is set to the node's name. This is why we maintain the hashmap so that we can map log messages on a node logger to the publisher for that node. It was also my understanding at the time that while nothing explicitly prevented two nodes with the same name it wasn't recommended. In light of all that, I added the exception that explicitly prevents a second node with the same name registering a logger because it then becomes unclear what the behavior of the system becomes. There isn't a way to map log messages coming from the OOP node loggers to the correct node publisher instance given only the node name. Additionally, as @sloretz points out, if we just warn and reuse the same logger for both node instances then when the node with the publisher gets destroyed it would stop the other instance from publishing to rosout. Additionally, I didn't feel it was the right choice that any node could secretly impact traffic going over another node instance's publishers under the hood. All these things could be fixed by adding slightly more complexity in the logger or accepting some of the pitfalls of the workarounds, but I'd like to know what the long term story is for supporting multiple nodes with the same name inside the same process before committing to a solution. |
|
@mkhansen-intel I believe this issue has been resolved by #384. If not, you can comment here and I can reopen the issue, |
Bug report
Required Info:
Operating System:
Installation type:
Version or commit hash:
master latest after "Publish logs to Rosout (Publish logs to Rosout #350)"
DDS implementation:
Client library (if applicable):
Steps to reproduce issue
Install navigation2
Expected behavior
Should launch fine without issue.
Actual behavior
Exception occurs, and crashes amcl node:
Additional information
SO, the launch file by default has this for the amcl portion:
When I comment out these 2 lines, setting the node_name and parameters, it works fine, but use_sim_time isn't set (which is needed).
I suspect the issue has something to do with the node_name field, but I don't know exactly what the issue is because I use nearly the same syntax for map_server in the same launch file and it works fine:
The only difference there being the use of a yaml file for a second parameter in the list.
This only recently stopped working (last week), and it coincided with #350, and the message was added in that PR, so it has to be related. I'm just not sure what the PR added and why having the node name and parameters makes it fail. I see the failure occurs here:
logging_rosout.c:156
Please help to understand why I'm hitting this error.
The text was updated successfully, but these errors were encountered: