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.

Sign up for GitHub

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

Jump to bottom

Rviz crashes when started with specific tf but not others #911

Closed
CaffeineSqurr opened this issue Aug 20, 2015 · 6 comments
Closed

Rviz crashes when started with specific tf but not others #911

CaffeineSqurr opened this issue Aug 20, 2015 · 6 comments
Labels
bug

Comments

@CaffeineSqurr
Copy link

I'm playing back a bag with a occupancy_grid, pointclouds, and a tf system. If the fixed frame is set to a specific (which happens to be the root of the tf tree) rviz will crash the moment bag playback starts. If the fixed frame is set to any other frame in the bag the playback will work correctly. After the first set of messages are displayed you can set the fixed frame to any other frame and rviz is fine. It doesn't matter how far into the bag I start playback the same thing happens. I've only included the gdb backtrace but I can include everything rviz prints on startup (its a lot of text) if desired.

**GDB Backtrace**
[ INFO] [1440030397.386498288, 1438292950.921057766] [/playback_rviz]: Font Arial using texture size 512x512
[ INFO] [1440030397.388154812, 1438292950.921564215] [/playback_rviz]: Info: Freetype returned null for character 160 in font Arial
[ INFO] [1440030397.388429254, 1438292950.921564215] [/playback_rviz]: Texture: ArialTexture: Loading 1 faces(PF_BYTE_LA,512x512x1) with 0 generated mipmaps from Image. Internal format is PF_BYTE_LA,512x512x1.
[ INFO] [1440030400.943647025, 1438292951.276780689] [/playback_rviz]: Texture: MapTexture0: Loading 1 faces(PF_L8,3072x3072x1) with 0 generated mipmaps from Image. Internal format is PF_L8,3072x3072x1.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) 
(gdb) backtrace
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff7affd01 in rviz::Property::Property(QString const&, QVariant, QString const&, rviz::Property*, char const*, QObject*) ()
   from /opt/ros/indigo/lib/librviz.so
#2  0x00007fff953edeae in rviz::TFDisplay::updateFrame(rviz::FrameInfo*) ()
   from /opt/ros/indigo/lib/libdefault_plugin.so
#3  0x00007fff953ef4d7 in rviz::TFDisplay::updateFrames() ()
   from /opt/ros/indigo/lib/libdefault_plugin.so
#4  0x00007fff953ef756 in rviz::TFDisplay::update(float, float) ()
   from /opt/ros/indigo/lib/libdefault_plugin.so
#5  0x00007ffff7aa7692 in rviz::DisplayGroup::update(float, float) ()
   from /opt/ros/indigo/lib/librviz.so
#6  0x00007ffff7b48bbe in rviz::VisualizationManager::onUpdate() ()
   from /opt/ros/indigo/lib/librviz.so
#7  0x00007ffff2e2387a in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#8  0x00007ffff2e27a31 in QObject::event(QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#9  0x00007ffff6edce2c in QApplicationPrivate::notify_helper(QObject*, QEvent*)
    () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#10 0x00007ffff6ee34a0 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#11 0x00007ffff2e0f4dd in QCoreApplication::notifyInternal(QObject*, QEvent*)
---Type <return> to continue, or q <return> to quit---
    () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#12 0x00007ffff2e3f323 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#13 0x00007ffff2e3c629 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#14 0x00007ffff1782e04 in g_main_context_dispatch ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007ffff1783048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007ffff17830ec in g_main_context_iteration ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007ffff2e3c7a1 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#18 0x00007ffff6f7ebe6 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#19 0x00007ffff2e0e0af in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#20 0x00007ffff2e0e3a5 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#21 0x00007ffff2e13b79 in QCoreApplication::exec() ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#22 0x0000000000400bc7 in main ()
@wjwwood
Copy link
Member

wjwwood commented Aug 20, 2015

@CaffeineSqurr is possible for you to share a bag file with just the /tf data that causes the problem?

@wjwwood wjwwood added the bug label Aug 20, 2015
@wjwwood wjwwood added this to the untargeted milestone Aug 20, 2015
@CaffeineSqurr
Copy link
Author

Here's the bag with only the tf messages
https://www.dropbox.com/s/zcfkn6afvkjgehk/tf_only.bag?dl=0

@wjwwood
Copy link
Member

wjwwood commented Aug 21, 2015

Thanks @CaffeineSqurr, I'll have a look at it as soon as I'm able. If you find out more or find a solution please let us know.

@arntanguy
Copy link
Contributor

This bug, along with the related ones #808 #616 (and the tf saving issue #834), I spent a bit of
time to try and look into the issue.
First, the debug trace goes as follow:

#0  0x00007ffff2f60940 in QVectorData::shared_null () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#1  0x00007ffff7a5c322 in rviz::Property::Property (this=0x114fa70, name=..., default_value=..., description=..., 
    parent=0x11ff4d0, changed_slot=0x0, receiver=0x0)
    at /home/arnaud/src/ext/catkin_ws/src/rviz/src/rviz/properties/property.cpp:72
#2  0x00007fffa1ac3ec2 in rviz::TFDisplay::updateFrame (this=0x92fc40, frame=0x11954d0)
    at /home/arnaud/src/ext/catkin_ws/src/rviz/src/rviz/default_plugin/tf_display.cpp:580
#3  0x00007fffa1ac1d58 in rviz::TFDisplay::updateFrames (this=0x92fc40)
    at /home/arnaud/src/ext/catkin_ws/src/rviz/src/rviz/default_plugin/tf_display.cpp:372
#4  0x00007fffa1ac1b8b in rviz::TFDisplay::update (this=0x92fc40, wall_dt=0.0298139174, ros_dt=0.0298169907)
    at /home/arnaud/src/ext/catkin_ws/src/rviz/src/rviz/default_plugin/tf_display.cpp:327
#5  0x00007ffff79cf064 in rviz::DisplayGroup::update (this=0x7be3e0, wall_dt=0.0298139174, ros_dt=0.0298169907)
    at /home/arnaud/src/ext/catkin_ws/src/rviz/src/rviz/display_group.cpp:234
#6  0x00007ffff7acea91 in rviz::VisualizationManager::onUpdate (this=0x7e6a10)
    at /home/arnaud/src/ext/catkin_ws/src/rviz/src/rviz/visualization_manager.cpp:320
#7  0x00007ffff7af1391 in rviz::VisualizationManager::qt_static_metacall (_o=0x7e6a10, 
    _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0x7fffffffcef0)
    at /home/arnaud/src/ext/catkin_ws/build/rviz/src/rviz/moc_visualization_manager.cxx:64
#8  0x00007ffff2c0e87a in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#9  0x00007ffff2c12a31 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#10 0x00007ffff6ca2e2c in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#11 0x00007ffff6ca94a0 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#12 0x00007ffff2bfa4dd in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#13 0x00007ffff2c2a323 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#14 0x00007ffff2c27629 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#15 0x00007ffff156de04 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007ffff156e048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007ffff156e0ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007ffff2c277a1 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#19 0x00007ffff6d44be6 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#20 0x00007ffff2bf90af in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#21 0x00007ffff2bf93a5 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#22 0x00007ffff2bfeb79 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#23 0x0000000000401080 in main (argc=3, argv=0x7fffffffd6b8)
    at /home/arnaud/src/ext/catkin_ws/src/rviz/src/rviz/main.cpp:41

Which corresponds to the following call in tf_display.cpp:580

 // Delete the old tree property.
delete frame->tree_property_;
frame->tree_property_ = NULL;

// If the parent has a tree property, make a new tree property for this frame.
 if( parent->tree_property_ )
{
frame->tree_property_ = new Property( QString::fromStdString( frame->name_ ), QVariant(), "", parent->tree_property_ );    
}

By doing a bit more gdb magic, we notice that the parent object has an adress, but that none of it's functions or attributes are accessible:

(gdb) frame 1
#1  0x00007ffff7a5c322 in rviz::Property::Property (this=0x114fa70, name=..., default_value=..., description=..., 
    parent=0x11ff4d0, changed_slot=0x0, receiver=0x0)
    at /home/arnaud/src/ext/catkin_ws/src/rviz/src/rviz/properties/property.cpp:72
72      parent->addChild( this );
(gdb) print parent
$1 = (rviz::Property *) 0x11ff4d0
(gdb) print parent->getName()

Program received signal SIGSEGV, Segmentation fault.
0x000000000120b950 in ?? ()
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(at 0x0x120b950) will be abandoned.
When the function is done executing, GDB will silently stop.

Okay, so, we've got some corrupted memory somewhere. I really am not surprised, considering how this property_tree_ is handled. It is destroyed/recreated here and there, in function either called by periodic timer update, or by manually using the reset button and so on...
Any particular reason for deleting and recreating this object all the time?

One quick testing hack "resolves" the issue. Commenting line 574

 // Delete the old tree property.
// delete frame->tree_property_;
frame->tree_property_ = NULL;

// If the parent has a tree property, make a new tree property for this frame.
if( parent->tree_property_ )
{
    frame->tree_property_ = new Property( QString::fromStdString( frame->name_ ), QVariant(), "", parent->tree_property_ );
}

However, this most likely creates a memory leak.

My guess is that the problem originates from race conditions between threads deleting the tree_property_ while others are trying to use it, thus causing random bugs.

Now, I don't really have the time to figure out how to solve this properly, it would be nice if someone more familiar with rviz could look into it.

The bug can be reproduced in several (not always crashing, but quite frequent with a fair amount of published tf):

  • Open rviz, load the tf plugin, then start playing a rosbag or publishing a fair amount of tfs.
    It crashes about 80% of the time.
    If you play the bag first, and then open rviz all seem fine.
  • Play around with the reset button

@arntanguy
Copy link
Contributor

@hershwg Why is the property tree deleted and then recreated, instead of just being updated?
The easiest way to fix this would be to never delete it in the first place, but update its elements wouldn't it?

arntanguy added a commit to arntanguy/rviz that referenced this issue Oct 9, 2015
@arntanguy
Fix ros-visualization#911 ros-visualization#616 : TF Segfaults on res…
2d6c813 
…et/create

Do not needlessly delete tree_property_ elements, update them instead.

Most likely fixes ros-visualization#808 too.
@arntanguy arntanguy mentioned this issue Oct 9, 2015
Merged
@wjwwood wjwwood closed this as completed in 606fe02 Oct 9, 2015
wjwwood added a commit that referenced this issue Oct 9, 2015
@wjwwood
Merge pull request #926 from arntanguy/fix-tf
4e0af42 
Fix #911 #616 : TF Segfaults on reset/update
@wjwwood
Copy link
Member

wjwwood commented Oct 9, 2015

Please comment if #926 doesn't solve the issue for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@arntanguy @wjwwood @CaffeineSqurr