You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using Publish Point on a map, rviz crashes with segmentation fault. The more markers (MarkerArray elements) are used on the map, the quicker the crash happens (from one click to maybe 6-7 clicks most commonly). It also seems that when a map has a lot of lines (lanelet2) and also lines that are thicker than for example the default Grid lines in rviz, then placing Publish Point on such map line crashes rviz faster.
When reading other (old) seemingly similar publish-point-rviz-crashes cases online, I suspected the nvidia driver at first but if I open rviz with the default grid and no other map (or any other custom elements) then no crash happens. And trying different nvidia drivers (535, 545) has not changed anything either. I also tried to build rviz from source but nothing changed. To find out what we can change on our map or about the used markers, I tried to debug and get as much info about the crash as possible. But I dont have experience here and I need help to pinpointing also any rviz components that can contribute to the problem. Can someone help to debug this so we can reach the root cause of the crashes?
OS Version: e.g. Ubuntu 20.04
ROS Distro: Noetic
RViz, Qt, OGRE, OpenGl version as printed by rviz:
[ INFO] [1706710074.282094334]: rviz version 1.14.20
[ INFO] [1706710074.282128215]: compiled against Qt version 5.12.8
[ INFO] [1706710074.282144720]: compiled against OGRE version 1.9.0 (Ghadamon)
[ INFO] [1706710074.289634354]: Forcing OpenGl version 0.
[ INFO] [1706710074.720466212]: OpenGL device: NVIDIA GeForce RTX 3060/PCIe/SSE2
[ INFO] [1706710074.720476748]: OpenGl version: 4,6 (GLSL 4,6).
Could you please provide more details to reproduce the error? Concretely, it would be great to get a Python program publishing the described map and marker items. A corresponding .rviz file would be also great.
Additionally, I would like to ask you to test the same issue w/o an NVIDIA card. We have noticed issues with NVIDIA drivers before (e.g. #1660). If the issue is not reproducible with the Mesa lib, I'm afraid we cannot fix it. (It's simply an NVIDIA driver issue then.)
As of now, the solution was to build rviz with Ogre v1.12 (instead of default 1.9.0). I have not managed to make it crash with this newer Ogre.
I believe it is simpler to use this solution (or workaround) and close this issue.
If Ogre 1.12 solves your problem, then it's an Ogre issue anyway. Unfortunately, the ROS community (particularly Gazebo guys) is stuck to this ancient release, which has a lot of known issues.
When using Publish Point on a map, rviz crashes with segmentation fault. The more markers (MarkerArray elements) are used on the map, the quicker the crash happens (from one click to maybe 6-7 clicks most commonly). It also seems that when a map has a lot of lines (lanelet2) and also lines that are thicker than for example the default Grid lines in rviz, then placing Publish Point on such map line crashes rviz faster.
When reading other (old) seemingly similar publish-point-rviz-crashes cases online, I suspected the nvidia driver at first but if I open rviz with the default grid and no other map (or any other custom elements) then no crash happens. And trying different nvidia drivers (535, 545) has not changed anything either. I also tried to build rviz from source but nothing changed. To find out what we can change on our map or about the used markers, I tried to debug and get as much info about the crash as possible. But I dont have experience here and I need help to pinpointing also any rviz components that can contribute to the problem. Can someone help to debug this so we can reach the root cause of the crashes?
OS Version: e.g. Ubuntu 20.04
ROS Distro: Noetic
RViz, Qt, OGRE, OpenGl version as printed by rviz:
System locale: en_US.UTF-8
1st run - rviz -l console log:
rviz_console_log.txt
gdb_rviz_console_log.txt
The text was updated successfully, but these errors were encountered: