search

yoshito-n-students / gazebo_continuous_track_example

How to use a realtime simulation of continuous tracks for Gazebo 7 & 9
MIT License
19 stars 7 forks source link

gzserver crashes on loading plugin #1

Closed naoki-mizuno closed 1 week ago

naoki-mizuno commented 5 years ago

以前ROSConJP会場で相談していたプラグインロード時にgzserverが落ちる問題ですが，Melodic + Gazebo 9.11.0でも発生しました．Kinetic + Gazebo 7.16.0でも同じ問題が発生しています．

と言っても「落ちる」以外のデバッグに使えそうな情報が今のところないので，とりあえずIssueだけ立てておきます．．．

環境

$ roslaunch gazebo_continuous_track_example example_track_simple_wheels_world.launch
... logging to /home/naoki/.ros/log/283ac4b0-ea2f-11e9-b48d-4ce676153c4f/roslaunch-diginnos-20734.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

xacro: in-order processing became default in ROS Melodic. You can drop the option.
started roslaunch server http://diginnos:42877/

SUMMARY
========

PARAMETERS
 * /example_track_simple_wheels/joint_state_controller/publish_rate: 10
 * /example_track_simple_wheels/joint_state_controller/type: joint_state_contr...
 * /example_track_simple_wheels/robot_description: <?xml version="1....
 * /example_track_simple_wheels/robot_state_publisher/tf_prefix: example_track
 * /example_track_simple_wheels/sprocket_velocity_controller/joint: sprocket_axle
 * /example_track_simple_wheels/sprocket_velocity_controller/type: velocity_controll...
 * /gazebo/enable_ros_network: True
 * /rosdistro: melodic
 * /rosversion: 1.14.3
 * /use_sim_time: True

NODES
  /
    gazebo (gazebo_ros/gzserver)
    gazebo_gui (gazebo_ros/gzclient)
  /example_track_simple_wheels/
    controller_starter (controller_manager/controller_manager)
    robot_state_publisher (robot_state_publisher/robot_state_publisher)

ROS_MASTER_URI=http://localhost:11311

process[gazebo-1]: started with pid [21116]
process[gazebo_gui-2]: started with pid [21121]
process[example_track_simple_wheels/controller_starter-3]: started with pid [21127]
process[example_track_simple_wheels/robot_state_publisher-4]: started with pid [21128]
[ WARN] [/example_track_simple_wheels/robot_state_publisher] [1570603741.150229699]: The root link body has an inertia specified in the URDF, but KDL does not support a root link with an inertia.  As a workaround, you can add an extra dummy link to your URDF.
[ INFO] [/gazebo] [1570603741.515859279]: Finished loading Gazebo ROS API Plugin.
[ INFO] [/gazebo] [1570603741.516433838]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...
[ INFO] [/gazebo_gui] [1570603741.582580862]: Finished loading Gazebo ROS API Plugin.
[ INFO] [/gazebo_gui] [1570603741.583202622]: waitForService: Service [/gazebo_gui/set_physics_properties] has not been advertised, waiting...
Segmentation fault (core dumped)
[gazebo-1] process has died [pid 21116, exit code 139, cmd /opt/ros/melodic/lib/gazebo_ros/gzserver -u -e ode /home/naoki/ros/workspaces/melodic/tmp/src/gazebo_continuous_track_example/world/example_track_simple_wheels.world __name:=gazebo __log:=/home/naoki/.ros/log/283ac4b0-ea2f-11e9-b48d-4ce676153c4f/gazebo-1.log].
log file: /home/naoki/.ros/log/283ac4b0-ea2f-11e9-b48d-4ce676153c4f/gazebo-1*.log
yoshito-okada commented 5 years ago

@naoki-mizuno 報告ありがとうございます．複数の環境で試していますが私の方では再現していません．私の方で再現するか，新しい情報の報告があれば解決に取り組みたいと思います．

Martin-Oehler commented 4 years ago

I had the same issue. I tried to build in debug to get a stack trace, however, that already fixed it. So for me, a clean build was the solution.

naoki-mizuno commented 4 years ago

I tried building the latest master s (https://github.com/yoshito-n-students/gazebo_continuous_track/commit/6b8023e10173dd929d83008abd32d5aa910162f4, https://github.com/yoshito-n-students/gazebo_continuous_track_example/commit/9dc578dea640d3147278bfff0a5754aed0ea4145), and found that if I build with build type Release I get a segfault, but if I build with Debug I don't.

@yoshito-okada Could you try building with -DCMAKE_BUILD_TYPE=Release and see if it crashes in your environment as well?

FYI my environment is:

Martin-Oehler commented 4 years ago

I can confirm this behavior, in Debug in runs fine, in Release it crashes. I am on the same environment as @naoki-mizuno.

yoshito-okada commented 4 years ago

Thank you for interesting reports! Confirmed too on Ubuntu 18.04 + Gazebo 9.

Also, I found that the returned value of sdf::initFile() became invalid when Release. I will look further this problem and get back here when I find something new. https://github.com/yoshito-n-students/gazebo_continuous_track/blob/6b8023e10173dd929d83008abd32d5aa910162f4/include/gazebo_continuous_track/gazebo_continuous_track_simple.hpp#L166

StefanFabian commented 4 years ago

I do not have a setup of this plugin but based on the information @yoshito-okada and @Martin-Oehler gathered I assume that the problem is that GZ_ASSERT evaluates to BOOST_ASSERT_MSG(expr, msg) (see here) which evaluates by default (can be changed with defines) to assert((expr) && (msg)) (see here). And that evaluates to ((void)0) if NDEBUG is defined as documented here. Hence, all these statements in the asserts are not executed if NDEBUG is defined which is the case for Release or RelWithDebInfo builds.

To fix

You should use a temp variable:

bool init_sdf_successful = sdf::initFile(ros::package::getPath("gazebo_continuous_track") +
                                         "/sdf/continuous_track_simple_plugin.sdf", fmt);
GZ_ASSERT(init_sdf_succesful, "Cannot initialize sdf by continuous_track_simple_plugin.sdf");

This way the statement will be executed in any case.

I would suggest running grep -r GZ_ASSERT and/or grep -ir assert in the repo to find other potential erroneous assert statements.

yoshito-okada commented 4 years ago

Thank you, @StefanFabian ! I wrongly expected GZ_ASSERT to trap an unrecoverable error regardless of Release or Debug.

@Martin-Oehler @naoki-mizuno To evaluate a condition and report an fatal error on loading a plugin to gzserver, I would change GZ_ASSERT(condition, msg) to if(condition) gzthrow(msg);. How do you like this change? I already confirmed this change worked for the ContinuousTrackSimple plugin in Release. Also, I guess gzserver will properly handle an exception from a plugin because a test case exists in the official repo.

naoki-mizuno commented 4 years ago

@yoshito-okada If you can push those changes to gazebo_continuous_track I can check if the problem is fixed in my environments.