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

librviz : Creating a MotionPlanning display in Noetic without crashing #1653

Closed
julien-audet opened this issue Aug 5, 2021 · 2 comments · Fixed by moveit/moveit#2833
Closed

Comments

@julien-audet
Copy link

julien-audet commented Aug 5, 2021

Hello,

I've been using librviz successfully for the past two years in my own Qt application for the visualization of a robot doing finishing tasks in ROS Kinetic with Ubuntu 16.04. Here's a code snippet of how I initialized librviz classes and added rviz::Display objects :

    // Construct and lay out render panel.
    rviz_render_panel_ = new rviz::RenderPanel();

    // Next we initialize the main RViz classes.
    rviz_manager_ = new rviz::VisualizationManager(rviz_render_panel_);
    rviz_render_panel_->initialize(rviz_manager_->getSceneManager(), rviz_manager_);
    rviz_manager_->initialize();
    rviz_manager_->startUpdate();
    
    // Create a display for MotionPlanning
    moveit_display_ = rviz_manager_->createDisplay("moveit_rviz_plugin/MotionPlanning", "MotionPlanning", true);

This used to work very well, but I've recently migrated from Kinetic to Noetic, and now, the last line (createDisplay) crashes without any warning or error for "moveit_rviz_plugin/MotionPlanning". It still works with any other rviz::Display objects, but crashes everytime when using "MotionPlanning". If I use rViz directly, I can easily create a MotionPlanning display and do A to B trajectories. Interestingly enough, it doesn't crash if I disable the display (isEnabled -> false) :

    moveit_display_ = rviz_manager_->createDisplay("moveit_rviz_plugin/MotionPlanning", "MotionPlanning", false);

But it crashes as soon as I enable it : moveit_display__->setEnabled(true)

So, my question is :

Is the MotionPlanning display object deprecated in the Noetic version of librviz (I wouldn't think so since it works in rViz)?

You can easily replicate the error using the librviz tutorial :
https://github.com/ros-visualization/visualization_tutorials/tree/noetic-devel/librviz_tutorial
And adding the following line after manager_->startupdate() :
rviz_manager_->createDisplay("moveit_rviz_plugin/MotionPlanning", "MotionPlanning", true);
It results as a "Segmentation fault (core dumped)" in this case.

Using gdb :

Thread 1 "myviz" received signal SIGSEGV, Segmentation fault.
#0  0x00007ffff7a96932 in QWidget::show() ()
    at /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#1  0x00007fff802005cf in moveit_rviz_plugin::MotionPlanningFrame::enable() ()
    at /opt/ros/noetic/lib/libmoveit_motion_planning_rviz_plugin_core.so.1.1.5
#2  0x00007ffff7783315 in rviz::Display::onEnableChanged() ()
    at /opt/ros/noetic/lib/librviz.so
#3  0x00007ffff776eab8 in  () at /opt/ros/noetic/lib/librviz.so
#4  0x00007ffff6c47300 in QMetaObject::activate(QObject*, int, int, void**) ()
    at /lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ffff78054ab in rviz::Property::setValue(QVariant const&) ()
    at /opt/ros/noetic/lib/librviz.so
#6  0x00007ffff778311b in rviz::Display::setEnabled(bool) ()
    at /opt/ros/noetic/lib/librviz.so
#7  0x00007ffff7862b28 in rviz::VisualizationManager::createDisplay(QString const&, QString const&, bool) () at /opt/ros/noetic/lib/librviz.so
#8  0x000055555556921c in MyViz::MyViz(QWidget*)
...

Using valgrind :

==10405== Invalid read of size 8
==10405==    at 0x4A32932: QWidget::show() (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==10405==    by 0x2F5525CE: moveit_rviz_plugin::MotionPlanningFrame::enable() (in /opt/ros/noetic/lib/libmoveit_motion_planning_rviz_plugin_core.so.1.1.5)
==10405==    by 0x502E314: rviz::Display::onEnableChanged() (in /opt/ros/noetic/lib/librviz.so)
==10405==    by 0x5019AB7: ??? (in /opt/ros/noetic/lib/librviz.so)
==10405==    by 0x5BE72FF: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.8)
==10405==    by 0x50B04AA: rviz::Property::setValue(QVariant const&) (in /opt/ros/noetic/lib/librviz.so)
==10405==    by 0x502E11A: rviz::Display::setEnabled(bool) (in /opt/ros/noetic/lib/librviz.so)
==10405==    by 0x510DB27: rviz::VisualizationManager::createDisplay(QString const&, QString const&, bool) (in /opt/ros/noetic/lib/librviz.so)
==10405==    by 0x11D21B: MyViz::MyViz(QWidget*) (myviz.cpp:62)
==10405==    by 0x123073: main (main.cpp:14)
==10405==  Address 0x28 is not stack'd, malloc'd or (recently) free'd
==10405== 
==10405== 
==10405== Process terminating with default action of signal 11 (SIGSEGV)
==10405==  Access not within mapped region at address 0x28
==10405==    at 0x4A32932: QWidget::show() (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==10405==    by 0x2F5525CE: moveit_rviz_plugin::MotionPlanningFrame::enable() (in /opt/ros/noetic/lib/libmoveit_motion_planning_rviz_plugin_core.so.1.1.5)
==10405==    by 0x502E314: rviz::Display::onEnableChanged() (in /opt/ros/noetic/lib/librviz.so)
==10405==    by 0x5019AB7: ??? (in /opt/ros/noetic/lib/librviz.so)
==10405==    by 0x5BE72FF: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.8)
==10405==    by 0x50B04AA: rviz::Property::setValue(QVariant const&) (in /opt/ros/noetic/lib/librviz.so)
==10405==    by 0x502E11A: rviz::Display::setEnabled(bool) (in /opt/ros/noetic/lib/librviz.so)
==10405==    by 0x510DB27: rviz::VisualizationManager::createDisplay(QString const&, QString const&, bool) (in /opt/ros/noetic/lib/librviz.so)
==10405==    by 0x11D21B: MyViz::MyViz(QWidget*) (myviz.cpp:62)
==10405==    by 0x123073: main (main.cpp:14)

I've investigated a bit and it seems like the parent QWidget of the MotionPlanningFrame is not initialized correctly (nullptr). Should I ask the question at the moveit repository?

Here's the link to the cpp files :
MotionPlanningFrame
MotionPlanningDisplay

At line 229 of MotionPlanningDisplay, we have the initialization of MotionPlanningFrame :

rviz::WindowManagerInterface* window_context = context_->getWindowManager();
frame_ = new MotionPlanningFrame(this, context_, window_context ? window_context->getParentWindow() : nullptr);

I guess the last argument of the second line is where the parent QWidget is initialized to a nullptr. context_ (rviz::DisplayContext) comes from the base class of MotionPlanningDisplay, that is rviz::Display, so I wouldn't think it is the problem.

Now, I've built Moveit from source and it seems like window_context is a nullptr. Is getWindowManager() deprecated?

Your environment

  • OS Version: Ubuntu 20.04
  • ROS Distro: Noetic
  • RViz, Qt, OGRE, OpenGl version as printed by rviz:
    [ INFO] [1628191103.549857876]: rviz version 1.14.8
    [ INFO] [1628191103.549899909]: compiled against Qt version 5.12.8
    [ INFO] [1628191103.549912271]: compiled against OGRE version 1.9.0 (Ghadamon)
    [ INFO] [1628191103.555191462]: Forcing OpenGl version 0.
    [ INFO] [1628191104.598819039]: Stereo is NOT SUPPORTED
    [ INFO] [1628191104.598860163]: OpenGL device: Mesa Intel(R) UHD Graphics (CML GT2)
    [ INFO] [1628191104.598878252]: OpenGl version: 4.6 (GLSL 4.6) limited to GLSL 1.4 on Mesa system.
@rhaschke
Copy link
Contributor

Sorry for the late reply. I think the core problem is that you (and the librviz tutorial) don't use a window manager at all:
The VisualizationManager is initialized w/o a second argument. Thus, getWindowManager returns NULL. In order to display the associated widget panel you need to specify a window manager.
Have you ever seen the panel in Kinetic? I'm not yet sure how/why it worked in Kinetic...
I will file a fixup in MoveIt to avoid the segfault, though.

@julien-audet
Copy link
Author

Sorry for not getting back to you sooner, I was away for two weeks. And you're right, I don't use a window manager at all. Still confused with why it worked in Kinetic. Thank you for the fixup! I'll try it tonight and then close the issue.

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

Successfully merging a pull request may close this issue.

2 participants