Gazebo | Ignition | Community
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

X forwarding + indirect 3D rendering = segmentation fault

Hi all

I am debugging gazebo with remote X forwarding. It works fine when I run it locally on my machine. It also works fine when I ssh with X forwarding to my own machine. However, when I use the same machine as a remote one and I ssh with X forwarding to it (from another machine) I get a segmentation fault.

When gazebo starts, a 3D world is correctly rendered on the local machine. I can also rotate the camera and the world is correctly redrawn. So far it looks like the indirect 3D rendering works fine. Things start to go wrong when I click on the image and gazebo, on the remote machine, tries to retrieve some information from OGRE.

I Debugged the program and I found out that when I click the image a piece of code similar to the following snippet is executed:

Ogre::HardwareIndexBuffer& buf = ... ;
if (buf.getType() == Ogre::HardwareIndexBuffer::IT_32BIT)
{
   uint32_t*  pLong = static_cast<uint32_t*>(buf.lock(Ogre::HardwareBuffer::HBL_READ_ONLY));
   idx0 = pLong[0];
   idx1 = pLong[1];
   ...
}

The exact code is at gazebo/rendering/Scene.cc:1590 (gazebo 7.3.1).

The indices retrieved from the Ogre::HardwareBuffer are then used to dereference an array of vertices (array of Ogre::Vector3 declared at gazebo/rendering/Scene.cc:1529). Some of the indices are fishy because they are definitely out of the bounds of the array of vertices and they cause a segmentation fault.

Is gazebo reading garbage from the remote GPU here? If so, is there any way that gazebo could possibly run remotely with X forwarding and indirect 3D rendering or am I trying to do something impossible? I am asking this because to me it looks like the problem is the fact that OpenGL commands are sent to the local client machine, whereas gazebo reads garbage from the remote GPU because it has been hardcoded to do so.

Thank you in advance for any input on this!

X forwarding + indirect 3D rendering = segmentation fault

Hi all

I am debugging gazebo with remote X forwarding. It Gazebo works fine when I run it locally on my machine. It Gazebo also works fine when I ssh with X forwarding to my own machine. However, when I use the same machine as a remote one and I ssh with X forwarding to it (from another machine) I get a segmentation fault.

When gazebo starts, a fault. This is a detailed list of what I do and what happens:

  1. ssh -Y to the remote machine were gazebo is installed.
  2. launch gazebo.
  3. gazebo starts and the GUI appears on the local machine.
  4. the 3D world is correctly rendered on the local machine. machine and I can also rotate the camera and the move/rotate it.
  5. click on the 3D world is correctly redrawn. So far it looks like the indirect 3D rendering works fine. Things start to go wrong when I click on the image and gazebo, on the remote machine, tries to retrieve some information from OGRE.

    on the local machine.
  6. gazebo crashes with a segmentation fault.

I Debugged the program and I found out that when I click the image a piece of code similar to the following snippet is executed:

Ogre::HardwareIndexBuffer& buf = ... ;
if (buf.getType() == Ogre::HardwareIndexBuffer::IT_32BIT)
{
   uint32_t*  pLong = static_cast<uint32_t*>(buf.lock(Ogre::HardwareBuffer::HBL_READ_ONLY));
   idx0 = pLong[0];
   idx1 = pLong[1];
   ...
}

The exact code is at gazebo/rendering/Scene.cc:1590 (gazebo 7.3.1).

The indices retrieved from the Ogre::HardwareBuffer are then used to dereference an array of vertices (array of Ogre::Vector3 declared at gazebo/rendering/Scene.cc:1529). Some of the indices are fishy because they are definitely out of the bounds of the array of vertices and they cause a the segmentation fault.

Is gazebo reading garbage from the remote GPU here? If so, is there any way that gazebo could possibly run remotely with X forwarding and indirect 3D rendering or am I trying to do something impossible? I am asking this because to me it looks like the problem is the fact that OpenGL commands are sent to the local client machine, whereas gazebo reads garbage from the remote GPU because it has been hardcoded to do so.

Thank you in advance for any input on this!

X forwarding + indirect 3D rendering = segmentation fault

Hi all

I am debugging gazebo with remote X forwarding. Gazebo works fine when I run it locally on my machine. Gazebo also works fine when I ssh with X forwarding to my own machine. However, when I use the same machine as a remote one and I ssh with X forwarding to it (from another machine) I get a segmentation fault. This is a detailed list of what I do and what happens:

  1. ssh -Y to the remote machine were gazebo is installed.<remote machine="" were="" gazebo="" is="" installed="">
  2. launch gazebo.
  3. gazebo starts and the GUI appears on the local machine.
  4. the 3D world is correctly rendered on the local machine and I can also move/rotate it.
  5. click on the 3D world on the local machine.
  6. gazebo crashes with a segmentation fault.

I Debugged the program and I found out that when I click the image a piece of code similar to the following snippet is executed:

Ogre::HardwareIndexBuffer& buf = ... ;
if (buf.getType() == Ogre::HardwareIndexBuffer::IT_32BIT)
{
   uint32_t*  pLong = static_cast<uint32_t*>(buf.lock(Ogre::HardwareBuffer::HBL_READ_ONLY));
   idx0 = pLong[0];
   idx1 = pLong[1];
   ...
}

The exact code is at gazebo/rendering/Scene.cc:1590 (gazebo 7.3.1).

The indices retrieved from the Ogre::HardwareBuffer are then used to dereference an array of vertices (array of Ogre::Vector3 declared at gazebo/rendering/Scene.cc:1529). Some of the indices are fishy because they are definitely out of the bounds of the array of vertices and they cause the segmentation fault.

Is gazebo reading garbage from the remote GPU here? If so, is there any way that gazebo could possibly run remotely with X forwarding and indirect 3D rendering or am I trying to do something impossible? I am asking this because to me it looks like the problem is the fact that OpenGL commands are sent to the local client machine, whereas gazebo reads garbage from the remote GPU because it has been hardcoded to do so.

Thank you in advance for any input on this!

X forwarding + indirect 3D rendering = segmentation fault

Hi all

I am debugging gazebo with remote X forwarding. Gazebo works fine when I run it locally on my machine. Gazebo also works fine when I ssh with X forwarding to my own machine. However, when I use the same machine as a remote one and I ssh with X forwarding to it (from another machine) I get a segmentation fault. This is a detailed list of what I do and what happens:

  1. ssh -Y <remote machine="" were="" gazebo="" is="" installed=""><remote_machine_were_gazebo_is_installed>
  2. launch gazebo.
  3. gazebo starts and the GUI appears on the local machine.
  4. the 3D world is correctly rendered on the local machine and I can also move/rotate it.
  5. click on the 3D world on the local machine.
  6. gazebo crashes with a segmentation fault.

I Debugged the program and I found out that when I click the image a piece of code similar to the following snippet is executed:

Ogre::HardwareIndexBuffer& buf = ... ;
if (buf.getType() == Ogre::HardwareIndexBuffer::IT_32BIT)
{
   uint32_t*  pLong = static_cast<uint32_t*>(buf.lock(Ogre::HardwareBuffer::HBL_READ_ONLY));
   idx0 = pLong[0];
   idx1 = pLong[1];
   ...
}

The exact code is at gazebo/rendering/Scene.cc:1590 (gazebo 7.3.1).

The indices retrieved from the Ogre::HardwareBuffer are then used to dereference an array of vertices (array of Ogre::Vector3 declared at gazebo/rendering/Scene.cc:1529). Some of the indices are fishy because they are definitely out of the bounds of the array of vertices and they cause the segmentation fault.

Is gazebo reading garbage from the remote GPU here? If so, is there any way that gazebo could possibly run remotely with X forwarding and indirect 3D rendering or am I trying to do something impossible? I am asking this because to me it looks like the problem is the fact that OpenGL commands are sent to the local client machine, whereas gazebo reads garbage from the remote GPU because it has been hardcoded to do so.

Thank you in advance for any input on this!