demoA errors #58

gjhenley · 2018-07-10T16:36:20Z

Huckleberry, When I try to run demoA I'm getting the following errors with the gazebo_gui and rvis processes:

process[gazebo_gui-4]: started with pid [139]
[ INFO] [1531239497.897672738]: Finished loading Gazebo ROS API Plugin.
[ INFO] [1531239497.899199288]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
process[spawn_urdf-5]: started with pid [184]
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
process[spawn_obstacles-6]: started with pid [249]
the rosdep view is empty: call 'sudo rosdep init' and 'rosdep update'
process[move_obstacles-7]: started with pid [340]
process[move_vehicle-8]: started with pid [386]
Segmentation fault (core dumped)
[gazebo_gui-4] process has died [pid 139, exit code 139, cmd /opt/ros/kinetic/lib/gazebo_ros/gzclient __name:=gazebo_gui __log:=/home/mavs/.ros/log/d9b6b346-845c-11e8-98d4-ecb1d7429ebc/gazebo_gui-4.log].
log file: /home/mavs/.ros/log/d9b6b346-845c-11e8-98d4-ecb1d7429ebc/gazebo_gui-4*.log

process[rviz-18]: started with pid [1783]
[ INFO] [1531239501.512498631]: rviz version 1.12.16
[ INFO] [1531239501.512547901]: compiled against Qt version 5.5.1
[ INFO] [1531239501.512574255]: compiled against OGRE version 1.9.0 (Ghadamon)
process[bootstrap-19]: started with pid [1918]
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Could not initialize OpenGL for RasterGLSurface, reverting to RasterSurface.
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
process[unpause_gazebo-20]: started with pid [2082]
[rviz-18] process has died [pid 1783, exit code -11, cmd /opt/ros/kinetic/lib/rviz/rviz -d /home/mavs/MAVs/ros/src/computing/perception/detection/obstacle_detection/resources/display.rviz __name:=rviz __log:=/home/mavs/.ros/log/d9b6b346-845c-11e8-98d4-ecb1d7429ebc/rviz-18.log].
log file: /home/mavs/.ros/log/d9b6b346-845c-11e8-98d4-ecb1d7429ebc/rviz-18*.log

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

huckl3b3rry87 · 2018-07-10T18:08:09Z

It looks like you are running into something like this
https://askubuntu.com/questions/834254/steam-libgl-error-no-matching-fbconfigs-or-visuals-found-libgl-error-failed-t

Can you follow the accepted answer and see if it works?

Thanks

gjhenley · 2018-07-11T16:14:19Z

It did not work. I'm wondering if this is not a conflict between the docker container library and the host library? I'm new to docker, so don't yet know much about it. What versions of docker/ros/gazebo are you using? Here's transcript of my test:

mavs@rosco-HP-Z440-Workstation:~$ gazebo
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

So looking at the suggestions in
https://askubuntu.com/questions/834254/steam-libgl-error-no-matching-fbconfigs-or-visuals-found-libgl-error-failed-t

In the host environment, there was no mesa libGL.so.1 just the nvidia one

rosco-HP-Z440-Workstation:~$ sudo ldconfig -p | grep -i gl.so
	libwayland-egl.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libwayland-egl.so.1
	libwayland-egl.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libwayland-egl.so
	libfltk_gl.so.1.3 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libfltk_gl.so.1.3
	libfltk_gl.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libfltk_gl.so
	libcogl.so.20 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcogl.so.20
	libQt5OpenGL.so.5 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5
	libQt5OpenGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so
	libQtOpenGL.so.4 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libQtOpenGL.so.4
	libQtOpenGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libQtOpenGL.so
	libOpenGL.so.0 (libc6,x86-64) => /usr/lib/nvidia-384/libOpenGL.so.0
	libOpenGL.so (libc6,x86-64) => /usr/lib/nvidia-384/libOpenGL.so
	libGL.so.1 (libc6,x86-64) => /usr/lib/nvidia-384/libGL.so.1
	libGL.so.1 (libc6) => /usr/lib32/nvidia-384/libGL.so.1
	libGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libGL.so
	libGL.so (libc6,x86-64) => /usr/lib/nvidia-384/libGL.so
	libGL.so (libc6) => /usr/lib32/nvidia-384/libGL.so
	libEGL.so.1 (libc6,x86-64) => /usr/lib/nvidia-384/libEGL.so.1
	libEGL.so.1 (libc6) => /usr/lib32/nvidia-384/libEGL.so.1
	libEGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libEGL.so
	libEGL.so (libc6,x86-64) => /usr/lib/nvidia-384/libEGL.so
	libEGL.so (libc6) => /usr/lib32/nvidia-384/libEGL.so

In the docker container, there was only one libGL.so.1 and it was from mesa

mavs@rosco-HP-Z440-Workstation:~$ sudo ldconfig -p | grep -i gl.so
	libwayland-egl.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libwayland-egl.so.1
	libwayland-egl.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libwayland-egl.so
	libQt5OpenGL.so.5 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5
	libQt5OpenGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so
	libQtOpenGL.so.4 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libQtOpenGL.so.4
	libQtOpenGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libQtOpenGL.so
	libGL.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
	libGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libGL.so
	libGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/mesa/libGL.so
	libEGL.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/mesa-egl/libEGL.so.1
	libEGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libEGL.so
	libEGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/mesa-egl/libEGL.so

It is a symbolic link which happens to point to libGL.so.1.2.0

mavs@rosco-HP-Z440-Workstation:~$ ls -l /usr/lib/x86_64-linux-gnu/mesa/libGL.so*
lrwxrwxrwx 1 root root     14 Jan 29 20:07 /usr/lib/x86_64-linux-gnu/mesa/libGL.so -> libGL.so.1.2.0
lrwxrwxrwx 1 root root     14 Jan 29 20:07 /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 -> libGL.so.1.2.0
-rw-r--r-- 1 root root 467520 Jan 29 20:08 /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0

Just for grins, removed the libGL.so.1 link anyway

mavs@rosco-HP-Z440-Workstation:~$ sudo rm /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
mavs@rosco-HP-Z440-Workstation:~$ ls -l /usr/lib/x86_64-linux-gnu/mesa/libGL.so*
lrwxrwxrwx 1 root root     14 Jan 29 20:07 /usr/lib/x86_64-linux-gnu/mesa/libGL.so -> libGL.so.1.2.0
-rw-r--r-- 1 root root 467520 Jan 29 20:08 /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0
mavs@rosco-HP-Z440-Workstation:~$ gazebo
gazebo: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory

So put it back:

mavs@rosco-HP-Z440-Workstation:~$ sudo ln /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0 /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
mavs@rosco-HP-Z440-Workstation:~$ gazebo
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

gjhenley · 2018-07-11T17:17:15Z

I spent more time looking for other suggestions and found a comment by user Medalibi on Mar 14 under the issue at link jessfraz/dockerfiles#253 which mentioned mounting the driver's library folder into the container and adding to the PATH and LD_LIBRARY_PATH, so I tried that and was finally able to get gazebo to run and thus demoA (though I only see one obstacle not 3, and had to zoom way out to see it). Doing this is certainly not very portable. I also noticed that the LD_LIBRARY_PATH contains /usr/local/nvidia/lib and /usr/local/nvidia/lib64, but those are none existant inside the mav container... maybe there is a missed dependency or something which should have installed nvidia folders there ?

mavs@rosco-HP-Z440-Workstation:~/.ros/log$ ls /usr/local/lib/
python2.7  python3.5
mavs@rosco-HP-Z440-Workstation:~/.ros/log$ 
mavs@rosco-HP-Z440-Workstation:~/.ros/log$ echo $LD_LIBRARY_PATH
/home/mavs/MAVs/ros/devel/lib:/opt/ros/kinetic/lib:/opt/ros/kinetic/lib/x86_64-linux-gnu:/usr/lib/nvidia-384:/usr/local/nvidia/lib:/usr/local/nvidia/lib64
mavs@rosco-HP-Z440-Workstation:~/.ros/log$

huckl3b3rry87 · 2018-07-11T18:36:15Z

First
@gjhenley thank you for looking into this, I did not see this error so it is very difficult for me to debug.

I am glad that you got it to work on your system, yes we will have to make sure that this issue is resolved. I am not sure what is happening. What version if Ubuntu are you running? Also what is your graphics card?

It seems like this may be pretty specific to your graphics drivers...

Second
In terms of the single obstacle you see (the picture on the documentation is outdated...) look at the launch files to see the obstacle field that is being used
https://github.com/JuliaMPC/MAVs/blob/master/ros/src/system/launch/demoA.launch

Notice it uses s9.yaml
https://github.com/JuliaMPC/MAVs/blob/master/ros/src/system/config/case/s9.yaml

this file only has a single obstacle

huckl3b3rry87 · 2018-07-11T19:48:25Z

also please put your code in quotes

like this

and if you want to ping me you use the @ symbol. Like @gjhenley

gjhenley · 2018-07-11T20:15:23Z

Do you have a physical desktop or server computer you are running MAVs on?
In your docker container, do you have /usr/local/nvidia/lib and /usr/local/nvidia/lib64 folders?
If so, isn't the dockerfile supposed to handle getting those populated with valid libraries?

I was running on Ubuntu 16.04 and it has a Nvidia Quadro K2200 with the nvidia driver version 384.

huckl3b3rry87 · 2018-07-11T23:14:40Z

Do you have a physical desktop or server computer you are running MAVs on?
Both A and B.

A: I have run MAVs on a number of laptops as well as physical desktops.
B: Currently MAVs has been built 52 times by random Amazon computers: see the .travis build. The build is still failing because I did not finish making the tests, but everything is installing properly as far as I can tell.

In your docker container, do you have /usr/local/nvidia/lib and /usr/local/nvidia/lib64 folders?
No. Look at the image here

mavs@febbo-HP-ZBook-17-G2:~$ cat /usr/local/nvidia/lib
cat: /usr/local/nvidia/lib: Is a directory
mavs@febbo-HP-ZBook-17-G2:~$ cat /usr/local/nvidia/lib64cat: /usr/local/nvidia/lib64: Is a directory

If so, isn't the dockerfile supposed to handle getting those populated with valid libraries?
No. Initially had it, but I removed it.
Ask mentioned in the MAVs Docker README.MD you need nvidia-docker.

It made the Dockerfile image smaller so that we can work towards testing using .travis. It reduced the build time from more that 45 minutes to about 20, see .travis difference in time between build 44 and 45 etc.

I was running on Ubuntu 16.04 and it has a Nvidia Quadro K2200 with the nvidia driver version 384.
I have not tested on this build, but I imagine that it will be fine once you get nvidia-docker.

gjhenley · 2018-07-12T15:24:17Z

Sorry, but I did follow the MAVSs Docker README.MD and I did install nvidia-docker a week or two ago. The suggested nvidia docker test:

# Test nvidia-smi with the latest official CUDA image
docker run --runtime=nvidia --rm nvidia/cuda nvidia-smi

succeeded with no errors.

I don't know what is causing the problem, but the gazebo built and installed inside the docker container has the earlier mentioned problem when using the /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 library (also inside the container) but works ok when using the /usr/lib/nvidia-384/libGL.so.1 library which I manually mapped from the host to make it visible inside the container and added to the LD_LIBRARY_PATH.

huckl3b3rry87 · 2018-07-12T15:31:38Z

OK, sorry for the misunderstanding. I thought it was a simple fix.

So, do you think that this program might be causing the issue?

Also, the mapping that works for the Docker file looks does not have /usr/lib/nvidia-384/.

The paths are /usr/local/nvidia/lib and /usr/local/nvidia/lib64 which can be seen here. Also the same as you mentioned in previos comments..

huckl3b3rry87 · 2018-07-12T15:48:01Z

Just to be clear, are able to run the demos now after this fix you made?

gjhenley · 2018-07-12T17:53:44Z

When I looked at your comments on github and click on the "this program" link I get a HTTP 404 Page not found error, so I didn't know what "this program" referred to. But in this email I was able to see that your are referring to the Dockerfile line 12 which is mesa-utils. Yes this probably is what installs the mesa version of libGL which somehow seems incompatible with the gazebo (at least gazebo fails when using this libGL), so it might be causing the issue. However, there needs to be a libGL provided by someone, and in the docker container, I don't see any other one, thus I took necessary steps to make one visible in the container.

…

________________________________ From: Huckleberry Febbo <notifications@github.com> Sent: Thursday, July 12, 2018 10:31 AM To: JuliaMPC/MAVs Cc: Henley, Greg; Mention Subject: Re: [JuliaMPC/MAVs] demoA errors (#58) OK, sorry for the misunderstanding. I thought it was a simple fix. So, you think that this program might be causing the issue https://github.com/JuliaMPC/MAVs/blob/master/docker/Dockerfile#L12 - You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#58 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AGGGrv4Z5zy71h9tKO5BHBL-1hA7cFWcks5uF2vagaJpZM4VJvqF>.

gjhenley · 2018-07-12T18:02:22Z

I'm not sure I understand what you mean by "Also, the mapping that works for the Docker file looks does not have /usr/lib/nvidia-384". I copied and edited the build.sh and run.sh and Dockerfile to include the /usr/lib/nvidia-384 in various places to get gazebo to work... fully realizing that most people may not have driver version 384 thus my comment about it not being very portable. I would have thought that either the nvidia-docker or some other mechanism would have taken care of getting the right/compatible libGL in place.

gjhenley · 2018-07-12T18:04:27Z

I am now able to run demoA, demoB, demoC, and demoE. The first time I run demoB it gave lots of warnings and 2 errors, I just killed it and ran a 2nd time and it eventually ran successfully.

demoD and demoF did not work. does the dockerfile handle installing chrono?

huckl3b3rry87 · 2018-07-12T19:44:32Z

@gjhenley OK. Thank you for explaining this to me and thank you for coming up with a fix on your machine.

Yeah, sometimes there are errors when you start up and you have to restart it.

I am glad that you are able to get demoA -C and E working. Actually, currently, I removed Chrono to strip down the Dockerfile and because while we were able to get it working, there are still a few kinks that need to be worked out before it is really ready for use.

huckl3b3rry87 · 2018-10-31T19:40:30Z

closing due to metaissue #89

huckl3b3rry87 mentioned this issue Sep 27, 2018

Segmentation fault with demoA #69

Closed

huckl3b3rry87 closed this as completed Oct 31, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

demoA errors #58

demoA errors #58

gjhenley commented Jul 10, 2018 •

edited by huckl3b3rry87

Loading

huckl3b3rry87 commented Jul 10, 2018

gjhenley commented Jul 11, 2018 •

edited by huckl3b3rry87

Loading

gjhenley commented Jul 11, 2018 •

edited by huckl3b3rry87

Loading

huckl3b3rry87 commented Jul 11, 2018 •

edited

Loading

huckl3b3rry87 commented Jul 11, 2018

gjhenley commented Jul 11, 2018

huckl3b3rry87 commented Jul 11, 2018 •

edited

Loading

gjhenley commented Jul 12, 2018

huckl3b3rry87 commented Jul 12, 2018 •

edited

Loading

huckl3b3rry87 commented Jul 12, 2018

gjhenley commented Jul 12, 2018 via email

gjhenley commented Jul 12, 2018

gjhenley commented Jul 12, 2018

huckl3b3rry87 commented Jul 12, 2018

huckl3b3rry87 commented Oct 31, 2018

demoA errors #58

demoA errors #58

Comments

gjhenley commented Jul 10, 2018 • edited by huckl3b3rry87 Loading

huckl3b3rry87 commented Jul 10, 2018

gjhenley commented Jul 11, 2018 • edited by huckl3b3rry87 Loading

gjhenley commented Jul 11, 2018 • edited by huckl3b3rry87 Loading

huckl3b3rry87 commented Jul 11, 2018 • edited Loading

huckl3b3rry87 commented Jul 11, 2018

gjhenley commented Jul 11, 2018

huckl3b3rry87 commented Jul 11, 2018 • edited Loading

gjhenley commented Jul 12, 2018

huckl3b3rry87 commented Jul 12, 2018 • edited Loading

huckl3b3rry87 commented Jul 12, 2018

gjhenley commented Jul 12, 2018 via email

gjhenley commented Jul 12, 2018

gjhenley commented Jul 12, 2018

huckl3b3rry87 commented Jul 12, 2018

huckl3b3rry87 commented Oct 31, 2018

gjhenley commented Jul 10, 2018 •

edited by huckl3b3rry87

Loading

gjhenley commented Jul 11, 2018 •

edited by huckl3b3rry87

Loading

gjhenley commented Jul 11, 2018 •

edited by huckl3b3rry87

Loading

huckl3b3rry87 commented Jul 11, 2018 •

edited

Loading

huckl3b3rry87 commented Jul 11, 2018 •

edited

Loading

huckl3b3rry87 commented Jul 12, 2018 •

edited

Loading