Rendering causes crash when gym is wrapped in a ROS node

[evenmarbles]

I wrote a ROS node wrapping openaigym to run the environments an then pass the action from another ROS. But for some reason the code crashes with exit code 139 whenever rendering is turned on. The program works fine without rendering.

Furthermore, when rendering is turned on, it starts by displaying the environment in the window, but crashes when updating the rendering after receiving its first action from the other node. To be more precise it crashes when executing the command glClearColor(1, 1, 1, 1) in gym.env.classic_control.rendering.py (so far I tried it for the CartPole and the MountainCar domains).

As an interesting tidbit, when I am running the ROS node openaigym wrapper, and sample actions in the node and pass it directly into the function dealing with updating the environment and rendering it (without involving the agent ROS node, the program runs just fine (doesn't crash).

So my best guess is that the crash is somehow related to using tcp (since this is how the information is passed from the agent to the environment) and pyglet/opengl.

[tlbtlbtlb]

Exit code 139 == segmentation fault.

How is the process connecting to the X server?

[evenmarbles]

The error shown below is without connecting to the X server. However, when I try to connect to the X server as follows:
$ xvfb-run --auto-servernum -s "-screen 0 1400x900x24" bash
$ rosrun ....

I am getting the following error:
pyglet.gl.glx_info.GLXInfoException: pyglet requires an X server with GLX

Checking:
$ glxinfo
Reveals the following error:
name of display: :99
Xlib: extension "GLX" missing on display ":99".
...
Error: couldn't find RGB GLX visual or fbconfig

Do you have any suggestions?

[tlbtlbtlb]

Your installation of xvfb doesn't support GLX (needed for OpenGL).

There is lots written about it at http://stackexchange.com/search?q=xvfb+GLX

Here's what worked for me on ubuntu 14.04 inside a Docker container on an AWS instance:

apt-get install \
    xorg-dev \
    libglu1-mesa libgl1-mesa-dev \
    xvfb \
    libxinerama1 libxcursor1 \

xvfb-run -a -s "-screen 0 1400x900x24 +extension RANDR" -- python XXX.py

[jietang]

@evenmarbles any updates here?

[justanotherminh]

@tlbtlbtlb Can you share the AMI you used? I can't seem to get pass the "pyglet requires an X server with GLX" error with your configuration.

[hholst80]

I get the same error as you @luongminh97. I was recommended to try http://www.karlrunge.com/x11vnc/Xdummy but opt-out and just disabled rendering for now. I also tried virtualgl which works good for glxgears and glxinfo but pyglet still wasn't happy.

[tlbtlbtlb]

I run this inside docker containers, based on 64-bit Ubuntu 14.04. I haven't tried directly inside an AMI-based system.

The X server log may reveal why it failed to enable GLX.

[DavidSanwald]

@luongminh97 @hholst80 @Faur

What @pemami4911 wrote on #366 (THANKS!) finally pointed me into the right direction.

I didn't xvfb and sadly also X-dummy to work for a long time but when I followed pemami4911's hint and installed the Nvidia driver with --no-opengl-files option and CUDA with --no-opengl-libs xvfb worked right away.
I did not have to do anything complicated, just installing drivers with --no-opengl-files and CUDA with --no-opengl-libs. Just in case I documented the necessary steps here

[vlad17]

@DavidSanwald / @tlbtlbtlb do you still do this? It works for me, but it seems that this forces rendering onto the CPU (just basing this off of watching nvidia-smi), and it'd be nice to render on the GPU (since they were made for this after all).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.