Mujoco-py: Linux Viewer Error: GLEW initalization error: Missing GL version

[jonasschneider]

[hmishra2250]

Yes it is! I am getting the following error:

ERROR: GLEW initalization error: Missing GL version

Tried each and every possible GUI/OpenGL library update, with and without Anaconda on python 3.5.2. Seems there is some problem with Context of glfw or Initialization.

[hmishra2250]

I have been trying to catch up with the cause of the error. I found that it's in the initialization of base class MjRenderContextWindow from which all viewer class inherits. Now, since this is packed as an Extension, my debugger can't see what is going inside.
I even tried with glfw, different settings and using initializations as done in Mujoco_py==0.5.7, and the glfw seems to work well.
I also tried adding some extra flags while building extensions such as -lGL and -lglew, but they didn't work because there is some other issue.

Another thing, I could not understand was what is the need of such kind of "building up and use" kind of structure, if ultimately we can't see the internal flow and debug. (Or maybe I am not experienced enough to know that we can!).

Please let me know what can be the possible problems and why did you prefer making extensions over just modules, so that I can also help in rectifying the problem.

Thanks

[iretiayo]

@hmishra2250 @jonasschneider Is there any update on how to get the Linux viewer GUI working? Or is there a recommended hack or work-around?
I use Python 3.5 on Ubuntu 16.04
Thanks in anticipation

[tartavull]

+1

[tartavull]

An ugly workaround is to write your own viewer @iretiayo

import glfw
import numpy as np
from OpenGL.GLU import *
from OpenGL.GL import *

class Viewer():

    def __init__(self, sim):
        self.sim = sim

        if not glfw.init():
            return
        # Create a windowed mode window and its OpenGL context
        self._window = glfw.create_window(640, 480, "Hello World", None, None)
        if not self._window:
            glfw.terminate()
            return

        # Make the window's context current
        glfw.make_context_current(self._window)

    def render(self):
        # Make the window's context current
        glfw.make_context_current(self._window)
        if glfw.window_should_close(self._window):
            glfw.terminate()

        self.image = self.sim.render(640,480).astype(np.float) / 255.0

        # Render here, e.g. using pyOpenGL
        self.texture = glGenTextures(1)
        glEnable(GL_TEXTURE_2D)
        glPixelStorei(GL_UNPACK_ALIGNMENT, 1)
        glBindTexture(GL_TEXTURE_2D, self.texture)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP)
        glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE)
        glTexImage2D(GL_TEXTURE_2D, 0,
                     GL_RGB,
                     self.image.shape[1], self.image.shape[0], 0,
                     GL_RGB,
                     GL_FLOAT,
                     self.image)
        glDisable(GL_TEXTURE_2D)

        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
        glClearColor(0., 0., 0., 0.)
        glClearDepth(1)
        glMatrixMode(GL_MODELVIEW)
        glLoadIdentity()
        glBindTexture(GL_TEXTURE_2D, self.texture)
        glEnable(GL_TEXTURE_2D)
        # draw a textured quad, shrink it a bit so the edge is clear
        glBegin(GL_QUADS)
        glTexCoord2f(0., 0.)
        glVertex3f(-0.9, -0.9, 0.)
        glTexCoord2f(1., 0.)
        glVertex3f(0.9, -0.9, 0.)
        glTexCoord2f(1., 1.)
        glVertex3f(0.9, 0.9, 0.)
        glTexCoord2f(0., 1.)
        glVertex3f(-0.9, 0.9, 0.)
        glEnd()
        glDisable(GL_TEXTURE_2D)

        # Swap front and back buffers
        glfw.swap_buffers(self._window)

        # Poll for and process events
        glfw.poll_events()

[tartavull]

Keep in mind that this is really slow compared to the native mujoco visualizer

[lukashermann]

+1

[Kukanani]

+1

[ethanabrooks]

+1

[ViktorM]

The same error.

[ViktorM]

Looks like it hasn't been fixed for almost 4 months. Are there any estimates when the bug can be fixed?

[ethanabrooks]

I have some insight into this one. It looks like mujoco produces this error on my system when it is built with libglewosmesa and libOSMesa but _succeeds_ when it's built with libglew instead. The problem is that I don't know how much of the code in mujoco-py depends on the mesa libraries and I don't really understand these graphics libraries that well.

I am getting some help from Emo on the MuJoCo forum. If I could also get some help from the mujoco-py team, I would be happy to work on a pull request.

[ViktorM]

Agrre, looks like it is broken for 1.5. As I've installed older mujoco-py version for mujoco 1.3.1 and it worked out of the box.

[lukashermann]

@lobachevzky so you mean you didn't get the error with mujoco-py if you build mujoco with libglew? It's weird because I can compile and run the c++ samples of mujoco 1.5 without getting an error, but mujoco-py crashes anyways.

[ethanabrooks]

Yes exactly. In fact, that is how I was able to diagnose the problem. So in the makefile that comes with mujoco, the instruction for basic.cpp reads:

g++ -O2 -I../include -L../bin -std=c++11 -mavx basic.cpp -lmujoco150 -lGL -lglew ../bin/libglfw.so.3 -o ../bin/basic

This works fine for me. But if I replace the above with

g++ -O2 -I../include -L../bin -std=c++11 -mavx basic.cpp -lmujoco150 -lGL -lglewosmesa -lOSMesa ../bin/libglfw.so.3 -o ../bin/basic

and try to run basic:

~/.mujoco/mjpro150/bin
❯ LD_LIBRARY_PATH=. ./basic ../model/humanoid.xml
ERROR: GLEW initalization error: Missing GL version

Press Enter to exit ...

[machinaut]

It looks like this is related to making sure we both link and load the correct GL library.

Neither GLEW or GLFW are the underlying GL library, though osmesa is one (others include gpu-specific GL libraries).

What happens when you link/load with whatever your current system libGL is?

[ethanabrooks]

What exactly is my current system libGL? It looks like the only libraries related to OpenGL on my LD_LIBRARY_PATH are the ones that come with mjPro150:

libglewegl.so
libglewosmesa.so
libglew.so
libglfw.so.3
libmujoco150nogl.so

[machinaut]

system gl should be libGL.so or similar. Are you able to use pyopengl (http://pyopengl.sourceforge.net/) or other openGL apps on the machine (glxinfo, glxgears) and see what GL libraries are loaded then.

[ethanabrooks]

glxgears works find. I won't include all of glxinfo but everything seems to come from NVIDIA, including OpenGL. libGL.so is getting linked with the -lGL flag, which I use in both the working and non-working compile commands.

[machinaut]

I'll try to get a linux desktop with nvidia drivers to test on.

Is this happening for folks on machines with other GL drivers (e.g. mesa), too?

[ethanabrooks]

I have libosmesa6 installed via apt. I tried uninstalling it and rebooting but it does not seem to have made any difference.

[ethanabrooks]

One interesting fact is that make egl works fine in mjpro150/sample on my computer. So the issue is not with egl per se. I compared mjpro150/sample/record.cpp with eglshim.c and the two are very similar, although eglshim.c includes a lot of additional stuff.

[donamin]

Hi @tartavull,
Are you sure that the code that you wrote is correct? It's showing me this runtime error:

Found 1 GPUs for rendering. Using device 0.
Could not make EGL context current
Traceback (most recent call last):
  File "/home/amin/Projects/baselines/test.py", line 239, in <module>
    viewer.render()
  File "/home/amin/Projects/baselines/test.py", line 28, in render
    self.image = self.sim.render(640,480).astype(np.float) / 255.0
  File "mjsim.pyx", line 149, in mujoco_py.cymj.MjSim.render
  File "mjsim.pyx", line 151, in mujoco_py.cymj.MjSim.render
  File "mjrendercontext.pyx", line 43, in mujoco_py.cymj.MjRenderContext.__init__
  File "mjrendercontext.pyx", line 99, in mujoco_py.cymj.MjRenderContext._setup_opengl_context
  File "opengl_context.pyx", line 128, in mujoco_py.cymj.OffscreenOpenGLContext.__init__
RuntimeError: Failed to initialize OpenGL

[Jerryxiaoyu]

@lobachevzky @machinaut I 'm getting the same ERROR.
ERROR: GLEW initalization error: Missing GL version
How can I fix it? Seems there is a problem with NIVIDIA GPU....
Thanks

[ethanabrooks]

@Jerryxiaoyu actually I believe that it has something to do with simultaneously compiling EGL and GLFW. I eventually wrote my own little wrapper script for mujoco which was mostly suited to my purposes but is general purpose enough that you are welcome to take a look: https://github.com/lobachevzky/mujoco

[Jerryxiaoyu]

@lobachevzky Thanks. Actually it has nothing to do with GPU because I tried to force to use CPU and got the same problem. But it's wired because there seems OK on another computer with the same enviornment (Ununtu 16.04 /Anaconda3)without Nvidia Titan 1080Ti.....

[ethanabrooks]

@Jerryxiaoyu make sure you call make clean and then recompile.

My advice would be to make sure that you can compile the sample scripts that come with mujoco:

cd ~/.mujoco/mjpro150/sample/
make

If that works, see if using the the libraries that are specified in that Makefile work with mujoco-py. You would need to change this line assuming that you are using linux.

I don't know exactly what is causing these problems, but there are a few likely culprits:

• As indicated by the line that I linked to, mujoco-py uses slightly different libraries than mujoco.
• It uses python GLFW instead of the GLFW that comes packaged with mujoco.
• The GPU version tries to use GLFW and EGL concurrently.

[Jerryxiaoyu]

@lobachevzky Following your advice, I checked the Makefile and it works.
Then I modified two lines according to your pull request #145. It solved my issue.
Thank you for your help.

[janniseis]

This error still occurs and unfortunately none of the suggested fixes seem to work for me.
I eventually worked around it by disabling my Nvidia GPU and using the integrated Intel GPU.

[SanderDalm]

I have the same issue. Can we please get an update on this? This issue makes mujoco-py all but unusable.

Version 131 still works for me, so if anyone needs a workaround downgrading seems to be an option.

[arunavanag591]

+1
@SanderDalm how do you downgrade the mujoco-py from 1.50. Even if I have Mujoco 131 my mujoco py is still looking for mjpro150

[SanderDalm]

@arunavanag591.

You downgrade mujoco-pay to the 0.5 range and download mujoco131 from the site and install it like you installed mujock150

[SanderDalm]

Mujoco-py*

[arunavanag591]

@SanderDalm so the older mujoco doesnt seem to have load_model
'mujoco_py' has no attribute 'load_model_from_path'
any workaround?

[SanderDalm]

@arunavanag591
Yes, if you're using it with OpenAi gym, downgrade gym to 0.7.4 and mujoco-py to 0.5.7.

This setup is currently working for me.

Also, OpenAi's roboschool is a cool and free alternative to mujoco.

[alexlee-gk]

The changes from #145 didn't fix the issue for me. I followed the advice from @lobachevzky, but I replaced glewegl with glew, and also added the libraries GL and glfw (see alexlee-gk@246bf1c; this works with GPU rendering on Ubuntu 14.04). This workaround breaks the EGL dependency though (so headless rendering within a docker container would probably not work). The right solution should properly resolve conflicts related to GLFW and EGL.

[bionick87]

Hi

I understood where the problem is, ie I analysed the flow of each class and the bugs seem to be into MyViewerBasic.py that it call builder.py.
Indeed, when you pass the sim object, it call cymj.MjRenderContextWindow
where cymj is a .so file: cymj.cpython-36m-x86_64-linux-gnu.so
under:
python3.6/site-packages/mujoco_py-1.50.1.0-py3.6.egg/mujoco_py/generated/_pyxbld_LinuxCPUExtensionBuilder/lib.linux-x86_64-3.6/mujoco_py/cymj.cpython-36m-x86_64-linux-gnu.so

cymj.cpython-36m-x86_64-linux-gnu.so is generated from the installation of mujoco_py

I try to solve the problem and keep you informed

Nicolo

[benelot]

@jonasschneider @machinaut : Deepmind control suite seems to have solved the problem using a workaround for now, maybe that could be applied to mujoco-py as well:
https://github.com/deepmind/dm_control/commit/3b736812407d821ec5d48bdea08ac53e00d78d2e

[Jin0932]

I have use to solve this question: https://blog.csdn.net/gsww404/article/details/80636676

[WarrG3X]

Adding
export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGLEW.so:/usr/lib/nvidia-390/libGL.so
to my .bashrc fixed the problem in my case.

I tested on Python 3.6 (Anaconda) with the following configurations -

• mjpro150, mujoco_py 1.5, gym 0.10.5
• mjpro131, mujoco_py 0.5.7, gym 0.9.1

[jperl]

In case anyone receives this error: ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libGLEW.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. this happened to me because my file was named libGLEW.so.2.0.

export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGLEW.so.2.0 worked.

[bjnortier]

@WarrG3X Thanks so much for this. Didn't need the nvidia one, just

export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGLEW.so

When running a simulation my second monitor becomes unresponsive but works again when the process quits.

[ecada]

Thank you for pointing out a solution to the error @jperl . I'm getting the same from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. error so I searched for the libGLEW.so's location just like you did and it was named libGLEW.so.1.13.
So I put the following in the bashrc as @WarrG3X recommended but still I'm getting the fatal error: GL/glew.h: No such file or directory error:

export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGLEW.so.1.13:/usr/lib/nvidia-384/libGL.so

I also tried the following with no luck:

export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGLEW.so.1.13:/usr/lib/x86_64-linux-gnu/libGL.so

[richardrl]

Even with the LD_PRELOAD fix, I can't call self.sim.render() without getting this error

[huangjiancong1]

@jonasschneider @glennpow @welinder @alfa07 @colah
Dear all, I have this issue:

My source package: https://github.com/RussellM2020/GMPS.git

System
mjpro150
mujoco-py<1.50.2,>=1.50.1
tensorflow-gpu 1.5
cuda 9.0 cudnn 7.1

I already have export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGLEW.so:/usr/lib/nvidia-410/libGL.so under ~/.bashrc

Output:

2019-04-27 10:20:52.345748: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1195] Creating TensorFlow device (/device:GPU:0) -> (device: 0, name: GeForce GTX 1050 Ti, pci bus id: 0000:01:00.0, compute capability: 6.1)
2019-04-27 10:21:20.170881 CST | itr #0 | Obtaining samples...
2019-04-27 10:21:20.171025 CST | itr #0 | Obtaining samples for iteration 0...
Found 1 GPUs for rendering. Using device 0.
Traceback (most recent call last):
  File "local_train.py", line 256, in <module>
    experiment(variant)
  File "local_train.py", line 236, in experiment
    algo.train()
  File "/home/jim/gmps/sandbox/rocky/tf/algos/batch_maml_polopt.py", line 396, in train
    logger.dump_tabular(with_prefix=False)
  File "/home/jim/anaconda2/envs/meta/lib/python3.5/site-packages/tensorflow/python/client/session.py", line 1530, in __exit__
    exec_type, exec_value, exec_tb)
  File "/home/jim/anaconda2/envs/meta/lib/python3.5/contextlib.py", line 77, in __exit__
    self.gen.throw(type, value, traceback)
  File "/home/jim/anaconda2/envs/meta/lib/python3.5/site-packages/tensorflow/python/framework/ops.py", line 4639, in get_controller
    yield default
  File "/home/jim/gmps/sandbox/rocky/tf/algos/batch_maml_polopt.py", line 396, in train
    logger.dump_tabular(with_prefix=False)
  File "/home/jim/anaconda2/envs/meta/lib/python3.5/contextlib.py", line 77, in __exit__
    self.gen.throw(type, value, traceback)
  File "/home/jim/gmps/rllab/misc/logger.py", line 156, in prefix
    yield
  File "/home/jim/gmps/sandbox/rocky/tf/algos/batch_maml_polopt.py", line 328, in train
    log_prefix=str(step),testitr=itr in self.testing_itrs,preupdate=True)
  File "/home/jim/gmps/sandbox/rocky/tf/algos/batch_maml_polopt.py", line 242, in obtain_samples
    paths = self.sampler.obtain_samples(itr=itr, reset_args=reset_args, return_dict=True, log_prefix=log_prefix, extra_input=self.extra_input, extra_input_dim=(self.extra_input_dim if self.extra_input is not None else 0), preupdate=preupdate)
  File "/home/jim/gmps/sandbox/rocky/tf/samplers/vectorized_sampler.py", line 110, in obtain_samples
    obses = self.vec_env.reset(reset_args)
  File "/home/jim/gmps/sandbox/rocky/tf/envs/vec_env_executor.py", line 32, in reset
    results = [env.reset(reset_args=arg) for env, arg in zip(self.envs, reset_args)]
  File "/home/jim/gmps/sandbox/rocky/tf/envs/vec_env_executor.py", line 32, in <listcomp>
    results = [env.reset(reset_args=arg) for env, arg in zip(self.envs, reset_args)]
  File "/home/jim/gmps/rllab/envs/proxy_env.py", line 13, in reset
    return self._wrapped_env.reset(*args, **kwargs)
  File "/home/jim/gmps/multiworld/core/finn_maml_env.py", line 54, in reset
    return self.get_flat_obs()
  File "/home/jim/gmps/multiworld/core/flat_goal_env.py", line 73, in get_flat_obs
    obs = self.wrapped_env._get_obs()
  File "/home/jim/gmps/multiworld/envs/mujoco/sawyer_xyz/push/sawyer_push.py", line 142, in _get_obs
    image = self.render(mode = 'nn')
  File "/home/jim/gmps/multiworld/envs/mujoco/sawyer_xyz/push/sawyer_push.py", line 167, in render
    image = self.get_image(width= im_size , height = im_size , camera_name = 'robotview_zoomed').transpose()/norm
  File "/home/jim/gmps/multiworld/envs/mujoco/mujoco_env.py", line 150, in get_image
    camera_name=camera_name,
  File "mjsim.pyx", line 149, in mujoco_py.cymj.MjSim.render
  File "mjsim.pyx", line 151, in mujoco_py.cymj.MjSim.render
  File "mjrendercontext.pyx", line 43, in mujoco_py.cymj.MjRenderContext.__init__
  File "mjrendercontext.pyx", line 108, in mujoco_py.cymj.MjRenderContext._setup_opengl_context
  File "opengl_context.pyx", line 128, in mujoco_py.cymj.OffscreenOpenGLContext.__init__
RuntimeError: Failed to initialize OpenGL

It seems that have the same question with @donamin issue

[Xuqisenvv]

add export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGLEW.so to .bashrc, and the name of "libGLEW.so" maybe different for diferent computer, that need to be checked firstly.

[Isaac009]

If you still have some issues try this out (for Ubuntu, I use Ubuntu 18.04)
Step 1
Run update command to update package repositories and get the latest package information.
sudo apt-get update -y

Step 2
Run the install command with -y

flag to quickly install the packages and dependencies.
sudo apt-get install -y libglew-dev

Got these from : https://zoomadmin.com/HowToInstall/UbuntuPackage/libglew-dev
and then

Step 3:
export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGLEW.so

This worked for me. Hope it works for you.

[HankerSia]

If you still have some issues try this out (for Ubuntu, I use Ubuntu 18.04)
Step 1
Run update command to update package repositories and get the latest package information.
sudo apt-get update -y

Step 2
Run the install command with -y

flag to quickly install the packages and dependencies.
sudo apt-get install -y libglew-dev

Got these from : https://zoomadmin.com/HowToInstall/UbuntuPackage/libglew-dev
and then

Step 3:
export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGLEW.so

This worked for me. Hope it works for you.

ok, i run sudo apt-get install -y libglew-dev
and add
export PATH=/usr/local/cuda-10.0/bin${PATH:+:${PATH}}
export LD_LIBRARY_PATH=/usr/local/cuda-10.0/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGLEW.so
it works for me!