ros-visualization / rviz

ROS 3D Robot Visualizer
BSD 3-Clause "New" or "Revised" License
841 stars 463 forks source link

Memory leak in kinetic #1386

Closed aPonza closed 5 years ago

aPonza commented 5 years ago

I'm launching roslaunch own_pkg calibration.launch which includes:

What I see in htop is the RAM filling up (in the arc of at most ~5m, even though the next picture says 22m), eventually using swap and finally crashing the pc. I also tried with 8GB more RAM just to see if it was a stabilization sort of issue but the behaviour is the same. Ordering the processes by memory used I see the problem is happening in something related to rviz:

Screenshot from 2019-07-15 15-27-04

The behaviour seems like it's a memory leak, and looking for memory leak PRs in RViz I saw #1294 (among other things which are already included in my version) and wanting to test if that fixes the leak I cloned the repo, checked out melodic-devel and git rebase -i kinetic-devel to get a compilable version for kinetic with the things added by the referenced PR (I couldn't manage to cherry-pick...).

pick 29ecde8 enable Travis again
pick 1bef2fb fix various catkin_lint issues
pick 26e920e remove executable flag from .ttf files
pick 0e8c842 suppress spurious warnings
pick a9d63cb update maintainer list
pick 707dc6f suppress cmake warnings
pick f230eab remove support for tf < 1.11.3
pick 6a769aa XML parse error message added (#1317)
pick 47af93a Revert "support multiple material for one link (#1079)"
pick e906f82 simplify material handling
pick 28fb778 support different materials for individual visuals
pick 83ac836 work-around for buggy urdf parser for visual materials

After fixing a compilation error (something with tinyxml2's Error() method, I used the compiler's suggestion) I re-launched my launch file and it seems to still be a problem, so unless I messed up something, this is not the issue I have.

I can provide the launch file and anything else needed, in case, but I'd rather have some help with what I can test to figure out where the root cause of the problem lies.

Also of note, last week I was seeing a QXcbWindow: Unhandled client message: "_COMPIZ_TOOLKIT_ACTION" in the log, which I'm not seeing anymore though.

Your environment

rhaschke commented 5 years ago

If you suspect rviz, verify the following:

aPonza commented 5 years ago

I can confirm no issues if RViz is not started. Also while doing this I found the leak isn't triggered if the master is born out of roslaunch instead of independently started via roscore. The culprit seems to be MotionPlanning (there's only TF other than that in the rviz.config that easy_handeye is using).

Also these are printed when adding that display:


[ INFO] - [/rviz_1563259975465041482::core::RobotModel::buildModel::93]: Loading robot model 'panda'...
[ INFO] - [/rviz_1563259975465041482::core::RobotModel::buildModel::93]: Loading robot model 'panda'...
[ INFO] - [/rviz_1563259975465041482::PlanningSceneMonitor::startSceneMonitor::949]: Starting scene monitor
[ INFO] - [/rviz_1563259975465041482::PlanningSceneMonitor::startSceneMonitor::955]: Listening to '/move_group/monitored_planning_scene'
[ INFO] - [/rviz_1563259975465041482::RobotInteraction::decideActiveComponents::97]: No active joints or end effectors found for group 'hand'. Make sure that kinematics.yaml is loaded in this node's namespace.
[ INFO] - [/rviz_1563259975465041482::RobotInteraction::decideActiveComponents::97]: No active joints or end effectors found for group 'hand'. Make sure that kinematics.yaml is loaded in this node's namespace.

I just checked about the hand config, and it's tied to using panda_arm_hand instead of panda_arm in panda_moveit config (we were talking about it here, so it seems it does have an impact, and I had not fixed it yet). No clue why it seems to be loading the robot model twice, is it expected?

EDIT: english

rhaschke commented 5 years ago

I'm afraid you need to narrow down the issue even more. When running panda_moveit_config's demo.launch, I don't see a continuous increase in memory, even over minutes. What I see, though, is an increase of 2MBytes in the first few minutes (probably due to TF buffers filling up). Then the memory usage settles.

aPonza commented 5 years ago

I too don't see a leak with demo.launch, I left it on overnight and in the now it is using the same memory as it was at the start. I'll do more tests on my side and let you know.

aPonza commented 5 years ago

The issue isn't there anymore... The only relevant changes are in easy_handeye, among them I moved stuff from using tf to using tf2. The commits aren't merged, but going back to master shows the issue again. Anyways not rviz related.