maliput_viewer2.sh crash with OGRE EXCEPTION: Vertex Buffer: Out of memory in GLHardwareVertexBuffer::lock #405

liangfok · 2021-05-13T19:32:21Z

Steps to reproduce:

Execute ./install/delphyne_gui/bin/maliput_viewer2.sh --malidrive_backend=malidrive2
Load https://github.com/ToyotaResearchInstitute/maliput_malidrive/blob/5c58bfc36ff9536c2a538326e007b301df64c541/maliput_malidrive/resources/TShapeRoad.xodr

Application should immediately crash with:

terminate called after throwing an instance of 'Ogre::InternalErrorException'
  what():  OGRE EXCEPTION(7:InternalErrorException): Vertex Buffer: Out of memory in GLHardwareVertexBuffer::lock at /build/ogre-1.9-B6QkmW/ogre-1.9-1.9.0+dfsg1/RenderSystems/GL/src/OgreGLHardwareVertexBuffer.cpp (line 124)
./install/delphyne_gui/bin/maliput_viewer2.sh: line 36: 13362 Aborted                 (core dumped) visualizer --layout=${DELPHYNE_GUI_RESOURCE_ROOT}/layouts/layout2_maliput_viewer.config "$@"

This is on a Lenovo T460p laptop running Ubuntu 18.04 with a GeForce 940MX GPU.

The text was updated successfully, but these errors were encountered:

francocipollone · 2021-05-17T12:37:35Z

I couldn't reproduce it yet. I will dig deeper.

liangfok · 2021-05-17T14:22:19Z

I am also unable to reproduce the problem. Using the same machine as in the original post, I was able to load TShapeRoad.xodr:

Since I was unable to reproduce the problem, I will close this ticket for now.

francocipollone · 2021-05-17T14:34:27Z

I am also unable to reproduce the problem. Using the same machine as in the original post, I was able to load TShapeRoad.xodr:

Since I was unable to reproduce the problem, I will close this ticket for now.

Thanks for the update.
Just wondering why the text isn't rendered as expected, the font size seems not to be right. Probably related to #407

liangfok · 2021-05-17T15:31:37Z

Are you referring to the text in the buttons on the right side of the screenshot? I so, I agree that is an issue.

liangfok · 2021-05-20T23:50:27Z

Just encountered this when loading maliput_malidrive/maliput_malidrive/resources/Figure8.xodr.

./install/delphyne_gui/bin/maliput_viewer2.sh --malidrive_backend=malidrive2

After specifying Figure8.xodr, the screen at first froze:

Then, after a while, the map appeared.

However, once I try to interact by rotating the view, it crashed:

terminate called after throwing an instance of 'Ogre::InternalErrorException'
  what():  OGRE EXCEPTION(7:InternalErrorException): Vertex Buffer: Out of memory in GLHardwareVertexBuffer::lock at /build/ogre-1.9-B6QkmW/ogre-1.9-1.9.0+dfsg1/RenderSystems/GL/src/OgreGLHardwareVertexBuffer.cpp (line 124)
./install/delphyne_gui/bin/maliput_viewer2.sh: line 36: 21538 Aborted                 (core dumped) visualizer --layout=${DELPHYNE_GUI_RESOURCE_ROOT}/layouts/layout2_maliput_viewer.config "$@"

agalbachicar · 2021-05-24T10:39:08Z

I confirm I can reproduce the bug.

francocipollone · 2021-05-27T19:16:36Z

This error points to that simply the video card runs out of memory. (VRAM).
In my case, I am not able to reproduce it because I am not using a pc with a dedicated gpu and it seems that it is managed differently.

I can take a look at how we are rendering things in the scene and try to identify if there is a more proper way to do this. (Probably checking how ignition performs this).

Is there a chance that you @scpeters have seen this kind of issue before?

scpeters · 2021-05-27T19:26:35Z

Is there a chance that you @scpeters have seen this kind of issue before?

I haven't seen this before

liangfok · 2021-05-27T19:28:31Z

For reference, here are the specs of the video card I am using:

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 450.119.03   Driver Version: 450.119.03   CUDA Version: 11.0     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  GeForce 940MX       Off  | 00000000:02:00.0 Off |                  N/A |
| N/A   65C    P0    N/A /  N/A |    757MiB /  2004MiB |     52%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|    0   N/A  N/A      2330      G   /usr/lib/xorg/Xorg                407MiB |
|    0   N/A  N/A      2510      G   /usr/bin/gnome-shell              128MiB |
|    0   N/A  N/A     15247      G   /usr/lib/firefox/firefox            0MiB |
|    0   N/A  N/A     19849      G   ...AAAAAAAAA= --shared-files      210MiB |
|    0   N/A  N/A     20107      G   /usr/lib/firefox/firefox            0MiB |
|    0   N/A  N/A     20114      G   /usr/lib/firefox/firefox            0MiB |
+-----------------------------------------------------------------------------+

Looks like it has 2GB of RAM.

agalbachicar · 2021-05-27T19:34:26Z

In my case:

$ nvidia-smi
Thu May 27 16:33:37 2021       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.130                Driver Version: 384.130                   |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 1060    Off  | 00000000:01:00.0 Off |                  N/A |
| N/A   63C    P3    19W /  N/A |   1550MiB /  6072MiB |      8%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0      1305      G   /usr/lib/xorg/Xorg                           836MiB |
|    0      2608      G   compiz                                       169MiB |
|    0      2940      G   ...-token=50F682ABB3395D5372029391B31E4C00   101MiB |
|    0     20782      G   ...-token=D422EDBD02F49F043FC6084E69295963    80MiB |
|    0     29007      G   ...AAgAAAAAAAAACAAAAAAAAAA= --shared-files   359MiB |
+-----------------------------------------------------------------------------+

liangfok · 2021-06-09T00:09:47Z

I ran into this bug trying to analyze straight_forward.xodr, which can be downloaded via the link below.

straight_forward.zip

To reproduce, open the viewer by executing the command below, then loading straight_forward.xodr:

./install/delphyne_gui/bin/maliput_viewer2.sh --malidrive_backend=malidrive2

The following viewer shows up:

Left-click on a lane. The viewer will immediately crash with the following error:

terminate called after throwing an instance of 'Ogre::InternalErrorException'
  what():  OGRE EXCEPTION(7:InternalErrorException): Vertex Buffer: Out of memory in GLHardwareVertexBuffer::lock at /build/ogre-1.9-B6QkmW/ogre-1.9-1.9.0+dfsg1/RenderSystems/GL/src/OgreGLHardwareVertexBuffer.cpp (line 124)
/home/liang/dev/maliput_ws/install/delphyne_gui/bin/maliput_viewer2.sh: line 36: 28035 Aborted                 (core dumped) visualizer --layout=${DELPHYNE_GUI_RESOURCE_ROOT}/layouts/layout2_maliput_viewer.config "$@"

It is 100% reproducible. The machine has relatively beefy NVIDIA GPUs:

$ nvidia-smi
Tue Jun  8 20:06:18 2021       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 430.50       Driver Version: 430.50       CUDA Version: 10.1     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  TITAN X (Pascal)    Off  | 00000000:03:00.0  On |                  N/A |
| 40%   68C    P0    68W / 250W |   1697MiB / 12194MiB |     12%      Default |
+-------------------------------+----------------------+----------------------+
|   1  TITAN X (Pascal)    Off  | 00000000:81:00.0 Off |                  N/A |
| 23%   37C    P8     9W / 250W |     12MiB / 12196MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0      3715      G   /usr/lib/xorg/Xorg                            72MiB |
|    0      4207      G   /usr/bin/gnome-shell                         114MiB |
|    0     16999      G   /usr/lib/xorg/Xorg                           678MiB |
|    0     17131      G   /usr/bin/gnome-shell                         489MiB |
|    0     32083      G   ...AAgAAAAAAAAACAAAAAAAAAA= --shared-files   315MiB |
+-----------------------------------------------------------------------------+

liangfok · 2021-06-09T00:14:46Z

The above error also happens if I use Malidrive 1.0:

maliput_viewer2.sh --malidrive_backend=opendrive_sdk

I can middle-click and drag to rotate the visualization, and scroll the mouse to zoom in/out. It only crashes when I left-click on a lane.

agalbachicar · 2021-06-09T12:11:16Z

I confirm it also happens with maliput_multilane.

agalbachicar · 2021-06-09T12:12:35Z

Checking this issue I noticed what I logged here: #407 (comment)

I suspect there is a misconfiguration of the nvidia drivers. Google search on Ogre exceptions as this one points in that direction as well.

liangfok · 2021-06-09T19:31:02Z

I tried the export LIBGL_ALWAYS_SOFTWARE=1 technique described here but that did not work. Same error when I click on a lane:

terminate called after throwing an instance of 'Ogre::InternalErrorException'
  what():  OGRE EXCEPTION(7:InternalErrorException): Vertex Buffer: Out of memory in GLHardwareVertexBuffer::lock at /build/ogre-1.9-B6QkmW/ogre-1.9-1.9.0+dfsg1/RenderSystems/GL/src/OgreGLHardwareVertexBuffer.cpp (line 124)
/home/liang/dev/maliput_ws/install/delphyne_gui/bin/maliput_viewer2.sh: line 36: 26980 Aborted                 (core dumped) visualizer --layout=${DELPHYNE_GUI_RESOURCE_ROOT}/layouts/layout2_maliput_viewer.config "$@"

agalbachicar · 2021-06-09T19:46:52Z

I did try it this morning and got the same result as you.

liangfok · 2021-06-09T19:47:11Z

This post indicates that rviz has a '-l' command line option that results in an Ogre.log file, which may contain useful information when Ogre 3D crashes. I wonder if we could get a similar log from Delphyne GUI's visualizer.

agalbachicar · 2021-06-09T19:48:08Z

I did check the ogre log (see inside the docker container at /home/username/.ignition/ogre.log ) but could not find anything relevant.

agalbachicar · 2021-06-09T19:49:17Z

I found an error in the NVidia dockerfile: https://github.com/ToyotaResearchInstitute/maliput_infrastructure/pull/210/files#diff-2cbc4ed79e6f64d9c41f1a01b9600e73c3fc34f9b735bdd4826703ade62e17acL48-L49 and https://github.com/ToyotaResearchInstitute/maliput_infrastructure/blob/main/docker/Dockerfile.nvidia#L20 . I will send a PR to fix but it did not fix the bug here.

liangfok · 2021-06-09T19:55:01Z

Thanks, I also checked my ~/.ignition/rendering/ogre.log and found nothing useful -- it just logged the same exception.

liangfok · 2021-06-09T21:14:04Z

Updated title of ticket to reflect the fact that it happens using multiple backends.

agalbachicar · 2021-06-15T12:13:52Z

I have built a workspace with ign libraries from sources and I have downgraded ign-gui3 from 3.5.1 to 3.5.0. Same result.

Running in bionic.

agalbachicar · 2021-06-15T12:14:53Z

BTW, it's important to point out that the error happens when running the RayTracing. I can move the view around, zoom in and out but when I click on the mesh it fails.

agalbachicar · 2021-06-15T13:02:36Z

I have also checked ign-rendering 3.4.0 without any luck. Note that ign-rendering 3.5.0 was released in Tue May 25.

agalbachicar · 2021-06-15T14:35:55Z

The non-nvidia docker image does not work out of the box. ign-gui / rendering fails with glx errors.

Next step: try ign samples to verify the same behavior.

agalbachicar · 2021-06-15T19:41:00Z

Next step: try ign samples to verify the same behavior.

I checked it and it is working just fine with default libraries from debian packages. Will start removing stuff from the maliput_viewer to identify what is causing the error because there is no need now to think there is something else.

francocipollone · 2021-06-15T21:00:38Z

Next step: try ign samples to verify the same behavior.

I checked it and it is working just fine with default libraries from debian packages. Will start removing stuff from the maliput_viewer to identify what is causing the error because there is no need now to think there is something else.

I would try disabling from the code the part where we do raytracing to get the lane selected. To see if it is related to that.

agalbachicar · 2021-06-16T11:52:01Z

I ran with gdb the application and found the following:

Thread 1 "visualizer" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) backtrace
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff5c9d921 in __GI_abort () at abort.c:79
#2  0x00007ffff62f2957 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff62f8ae6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff62f8b21 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff62f8d54 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007fffbe51aaca in Ogre::GLHardwareVertexBuffer::lockImpl(unsigned long, unsigned long, Ogre::HardwareBuffer::LockOptions) ()
   from /usr/lib/x86_64-linux-gnu/OGRE-1.9.0/RenderSystem_GL.so
#7  0x00007fffbe516236 in ?? () from /usr/lib/x86_64-linux-gnu/OGRE-1.9.0/RenderSystem_GL.so
#8  0x00007fffccfd9cb2 in ignition::rendering::v3::OgreRayQuery::MeshInformation(Ogre::Mesh const*, unsigned long&, Ogre::Vector3*&, unsigned long&, unsigned long*&,
ignition::math::v6::Vector3<double> const&, ignition::math::v6::Quaternion<double> const&, ignition::math::v6::Vector3<double> const&) () from /usr/lib/x86_64-linux-gnu/ign-rendering-3/engine-plugins/libignition-rendering-ogre.so
#9  0x00007fffccfda979 in ignition::rendering::v3::OgreRayQuery::ClosestPoint() ()
   from /usr/lib/x86_64-linux-gnu/ign-rendering-3/engine-plugins/libignition-rendering-ogre.so
#10 0x00007fffbc0b9174 in delphyne::gui::MaliputViewerPlugin::ScreenToScene (this=this@entry=0x5555564329d0, _screenX=468,
    _screenY=<optimized out>)
    at /home/agalbachicar/maliput_ws/src/delphyne_gui/delphyne_gui/visualizer/maliput_viewer_plugin/maliput_viewer_plugin.cc:723
#11 0x00007fffbc0c205a in delphyne::gui::MaliputViewerPlugin::MouseClickHandler (this=0x5555564329d0,
    _mouseEvent=_mouseEvent@entry=0x7fffffffc600)
    at /home/agalbachicar/maliput_ws/src/delphyne_gui/delphyne_gui/visualizer/maliput_viewer_plugin/maliput_viewer_plugin.cc:591
#12 0x00007fffbc0c3c22 in delphyne::gui::MaliputViewerPlugin::eventFilter (this=0x5555564329d0, _obj=0x555556422d60,
    _event=0x7fffffffc600)
    at /home/agalbachicar/maliput_ws/src/delphyne_gui/delphyne_gui/visualizer/maliput_viewer_plugin/maliput_viewer_plugin.cc:571
#13 0x00007ffff6ae15bc in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x00007ffff6ae16af in QCoreApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x00007ffff6ae176a in QCoreApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007ffff6ae18d8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x00007ffff47c48e0 in QQuickWindow::sendEvent(QQuickItem*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#18 0x00007ffff47c7f71 in QQuickWindowPrivate::deliverMatchingPointsToItem(QQuickItem*, QQuickPointerEvent*, QSet<QQuickItem*>*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#19 0x00007ffff47c897a in QQuickWindowPrivate::deliverPressEvent(QQuickPointerEvent*, QSet<QQuickItem*>*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#20 0x00007ffff47c8d39 in QQuickWindowPrivate::deliverMouseEvent(QQuickPointerMouseEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#21 0x00007ffff47c95d5 in QQuickWindowPrivate::deliverPointerEvent(QQuickPointerEvent*) ()

When inspecting how things are done between ignition::gui::Scene3D plugin and our MaliputViewerPlugin to handle the RayQuery query I identified that in the former it runs in a QThread which is bound to the OpenGL context running behind the scenes. That is not our case. I could also verify it by commenting out the call to MouseClickHandler(mouseEvent).

I'll investigate how easy is to execute a task in an OpenGL context through ignition without breaking the rendering pipeline that is already available in ign-gui Scene3D plugin.

@scpeters I think you might be interested in passing this information down to ignition gui and rendering folks.

scpeters · 2021-06-17T00:39:36Z

I think this is related to #393; I guess I forgot to come back to this

scpeters · 2021-06-17T00:41:26Z

I think we should cache the mouse event data and wait for the Render event callback to call ScreenToScene

francocipollone · 2021-06-17T12:33:15Z

I think we should cache the mouse event data and wait for the Render event callback to call ScreenToScene

Yes, yesterday we discussed this with @agalbachicar and we believe it is related to it. He will install by source and try these new changes in ign-gui3 that aren't released yet. By the way, a released for ign-gui3 is planned to happen this week so we won't need to specially ask for it.

scpeters · 2021-06-17T16:01:19Z

I think we should cache the mouse event data and wait for the Render event callback to call ScreenToScene

Yes, yesterday we discussed this with @agalbachicar and we believe it is related to it. He will install by source and try these new changes in ign-gui3 that aren't released yet. By the way, a released for ign-gui3 is planned to happen this week so we won't need to specially ask for it.

I had previously looked at the code that was merged, and there is one bit of functionality that is missing. The *ClickToScene events provide a Vector3d but don't provide the distance to the object or a bool indicating whether an object was clicked on (see discussion in gazebosim/gz-gui#209 (comment)). Unfortunately, these data structures were added in gazebosim/gz-gui#148 and have already been released, so we can't change them. I can look into adding a separate data structure alongside it with the extra info, which is not very clean, but I will check with Louise about what to do.

We currently use the knowledge of whether something was clicked or not, and deselect if nothing was clicked, so I think that extra data field is important.

francocipollone · 2021-06-17T16:10:36Z

I think we should cache the mouse event data and wait for the Render event callback to call ScreenToScene

Yes, yesterday we discussed this with @agalbachicar and we believe it is related to it. He will install by source and try these new changes in ign-gui3 that aren't released yet. By the way, a released for ign-gui3 is planned to happen this week so we won't need to specially ask for it.

I had previously looked at the code that was merged, and there is one bit of functionality that is missing. The *ClickToScene events provide a Vector3d but don't provide the distance to the object or a bool indicating whether an object was clicked on (see discussion in ignitionrobotics/ign-gui#209 (comment)). Unfortunately, these data structures were added in ignitionrobotics/ign-gui#148 and have already been released, so we can't change them. I can look into adding a separate data structure alongside it with the extra info, which is not very clean, but I will check with Louise about what to do.

We currently use the knowledge of whether something was clicked or not, and deselect if nothing was clicked, so I think that extra data field is important.

Good point.

This is what is returned when the cast doesn't intersects an object:
(From here)

  // Set point to be 10m away if no intersection found
  return this->dataPtr->rayQuery->Origin() +
      this->dataPtr->rayQuery->Direction() * 10;

I wonder if we could use that info to know if a lane was hit or not.

scpeters · 2021-06-17T16:52:48Z

Good point.

This is what is returned when the cast doesn't intersects an object:
(From here)
  // Set point to be 10m away if no intersection found
  return this->dataPtr->rayQuery->Origin() +
      this->dataPtr->rayQuery->Direction() * 10;
I wonder if we could use that info to know if a lane was hit or not.

we call GetLaneFromWorldPosition using the Vector3d from the event. I imagine we could call Lane::ToLanePosition and see if the lane h coordinate is close to 0? It's kind of a hack but might work

agalbachicar · 2021-06-17T17:21:28Z

FYI, RoadGeometry::ToRoadPosition() already has that logic (minimize h) as one of the decision rules.

scpeters · 2021-06-17T22:00:44Z

I think we should cache the mouse event data and wait for the Render event callback to call ScreenToScene

Yes, yesterday we discussed this with @agalbachicar and we believe it is related to it. He will install by source and try these new changes in ign-gui3 that aren't released yet. By the way, a released for ign-gui3 is planned to happen this week so we won't need to specially ask for it.

the ign-gui 3.6.0 release is imminent gazebosim/gz-gui#233

scpeters · 2021-06-19T08:57:03Z

Good point.
This is what is returned when the cast doesn't intersects an object:
(From here)
  // Set point to be 10m away if no intersection found
  return this->dataPtr->rayQuery->Origin() +
      this->dataPtr->rayQuery->Direction() * 10;
I wonder if we could use that info to know if a lane was hit or not.
we call GetLaneFromWorldPosition using the Vector3d from the event. I imagine we could call Lane::ToLanePosition and see if the lane h coordinate is close to 0? It's kind of a hack but might work

I've started testing this approach with ign-gui3 3.6.0 debs in eb947ea. I'm currently running into a bunch of seg-faults related to the MouseHover action, which I think is a bug in ign-gui3 (gazebosim/gz-gui#209 (comment))

agalbachicar · 2021-06-21T14:17:03Z

I sent #433 which solves the problem here but exposes the problem in ign-gui that @scpeters commented in #405 (comment)

francocipollone · 2021-07-05T19:55:10Z

I just got a new laptop with nvidia gpu and it is interesting that I wasn't able to reproduce the error:

franco@a2d19cf4ac08:~/maliput_ws$ nvidia-smi
Mon Jul  5 19:51:07 2021       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 460.80       Driver Version: 460.80       CUDA Version: N/A      |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  GeForce GTX 1650    Off  | 00000000:01:00.0  On |                  N/A |
| N/A   48C    P5     8W /  N/A |     75MiB /  3911MiB |     37%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
+-----------------------------------------------------------------------------+

agalbachicar · 2021-07-26T12:35:14Z

Resuming the work on this issue. The error is still reproducible in bionic with an updated graphic card driver for me:

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 460.91.03    Driver Version: 460.91.03    CUDA Version: N/A      |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  GeForce GTX 1060    Off  | 00000000:01:00.0 Off |                  N/A |
| N/A   58C    P5    10W /  N/A |    412MiB /  6078MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
+-----------------------------------------------------------------------------+

agalbachicar · 2021-08-03T12:24:54Z

By trying #446 and #423 together in foxy, I could not reproduce this bug using the maliput_viewer2. That points in the direction that this is a bionic specific bug and we could get rid of it by migrating to focal. Another reason to move faster.

agalbachicar · 2021-08-09T11:01:51Z

@francocipollone confirmed this error is not reproducible in focal. I'm closing this ticket in favor of using all delphyne repos in focal and deprecating its use in bionic.

liangfok changed the title ~~maliput_viewer2.sh crash when loading TShapeRoad.xodr using malidrive2 backend~~ maliput_viewer2.sh crash when loading TShapeRoad.xodr using Malidrive2 May 13, 2021

liangfok closed this as completed May 17, 2021

liangfok changed the title ~~maliput_viewer2.sh crash when loading TShapeRoad.xodr using Malidrive2~~ maliput_viewer2.sh crash when using 'malidrive2' backend May 20, 2021

liangfok reopened this May 20, 2021

This was referenced May 31, 2021

Deprecates ign_gui0-based visualizer. #423

Merged

Migrate to newer version of ignition-gui #332

Closed

liangfok changed the title ~~maliput_viewer2.sh crash when using 'malidrive2' backend~~ maliput_viewer2.sh crash with OGRE EXCEPTION(7:InternalErrorException): Vertex Buffer: Out of memory in GLHardwareVertexBuffer::lock Jun 9, 2021

liangfok changed the title ~~maliput_viewer2.sh crash with OGRE EXCEPTION(7:InternalErrorException): Vertex Buffer: Out of memory in GLHardwareVertexBuffer::lock~~ maliput_viewer2.sh crash with OGRE EXCEPTION: Vertex Buffer: Out of memory in GLHardwareVertexBuffer::lock Jun 9, 2021

agalbachicar mentioned this issue Jun 10, 2021

Fix and ENV variable in Dockerfile.nvidia and reorder the file to match the old sequence. maliput/maliput_infrastructure#214

Merged

agalbachicar mentioned this issue Jun 21, 2021

Solves crash on RayQuery #433

Merged

agalbachicar mentioned this issue Aug 3, 2021

Replaces AMENT_CURRENT_PREFIX by COLCON_PREFIX_PATH #446

Merged

agalbachicar closed this as completed Aug 9, 2021

maliput_viewer2.sh crash with OGRE EXCEPTION: Vertex Buffer: Out of memory in GLHardwareVertexBuffer::lock #405

maliput_viewer2.sh crash with OGRE EXCEPTION: Vertex Buffer: Out of memory in GLHardwareVertexBuffer::lock #405

Comments

liangfok commented May 13, 2021

francocipollone commented May 17, 2021

liangfok commented May 17, 2021

francocipollone commented May 17, 2021

liangfok commented May 17, 2021 • edited Loading

liangfok commented May 20, 2021 • edited Loading

agalbachicar commented May 24, 2021

francocipollone commented May 27, 2021

scpeters commented May 27, 2021

liangfok commented May 27, 2021 • edited Loading

agalbachicar commented May 27, 2021

liangfok commented Jun 9, 2021

liangfok commented Jun 9, 2021 • edited Loading

agalbachicar commented Jun 9, 2021

agalbachicar commented Jun 9, 2021

liangfok commented Jun 9, 2021

agalbachicar commented Jun 9, 2021

liangfok commented Jun 9, 2021

agalbachicar commented Jun 9, 2021 • edited Loading

agalbachicar commented Jun 9, 2021

liangfok commented Jun 9, 2021

liangfok commented Jun 9, 2021

agalbachicar commented Jun 15, 2021

agalbachicar commented Jun 15, 2021

agalbachicar commented Jun 15, 2021

agalbachicar commented Jun 15, 2021

agalbachicar commented Jun 15, 2021

francocipollone commented Jun 15, 2021

agalbachicar commented Jun 16, 2021

scpeters commented Jun 17, 2021

scpeters commented Jun 17, 2021

francocipollone commented Jun 17, 2021

scpeters commented Jun 17, 2021

francocipollone commented Jun 17, 2021

scpeters commented Jun 17, 2021

agalbachicar commented Jun 17, 2021

scpeters commented Jun 17, 2021

scpeters commented Jun 19, 2021

agalbachicar commented Jun 21, 2021

francocipollone commented Jul 5, 2021

agalbachicar commented Jul 26, 2021

agalbachicar commented Aug 3, 2021

agalbachicar commented Aug 9, 2021

liangfok commented May 17, 2021 •

edited

Loading

liangfok commented May 20, 2021 •

edited

Loading

liangfok commented May 27, 2021 •

edited

Loading

liangfok commented Jun 9, 2021 •

edited

Loading

agalbachicar commented Jun 9, 2021 •

edited

Loading