Error message: terminate called after throwing an instance of 'gazebo::common::Exception' AL lib: (WW) alcCloseDevice: Releasing context 0x563d9c1feb70 AL lib: (WW) alcSetError: Error generated on device (nil), code 0xa002 F31 on ThinkPad x260 (Intel Core i7-6600U @ 4x 3.4GHz, Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2))
I'm seeing the same behavior. I'm fairly confident that these reports are the same issue: https://retrace.fedoraproject.org/faf/reports/2745154/ https://retrace.fedoraproject.org/faf/reports/2824832/
Running with --verbose gets: [Err] [WindowManager.cc:132] Unable to create the rendering window [Err] [WindowManager.cc:132] Unable to create the rendering window [Err] [WindowManager.cc:132] Unable to create the rendering window [Err] [WindowManager.cc:132] Unable to create the rendering window [Err] [WindowManager.cc:132] Unable to create the rendering window [Err] [WindowManager.cc:132] Unable to create the rendering window [Err] [WindowManager.cc:132] Unable to create the rendering window [Err] [WindowManager.cc:132] Unable to create the rendering window [Err] [WindowManager.cc:132] Unable to create the rendering window [Err] [WindowManager.cc:132] Unable to create the rendering window [Err] [WindowManager.cc:139] EXCEPTION: Unable to create the rendering window Unfortunately gazebo is swallowing the underlying OGRE exception when it can't create the rendering window, I'll try to see what is happening underneath.
I updated the code responsible for the output above to write the exception text as part of the error message: [Err] [WindowManager.cc:132] Unable to create the rendering window: OGRE EXCEPTION(3:RenderingAPIException): Invalid parentWindowHandle (wrong server or screen) in GLXWindow::create at /builddir/build/BUILD/ogre-1.9.0/RenderSystems/GL/src/GLX/OgreGLXWindow.cpp (line 240) It looks like it's an OGRE/Wayland issue. I found a similar error report from rviz here: https://github.com/ros-visualization/rviz/issues/1442 The work-around listed in the bug report works, and gazebo launches properly: QT_QPA_PLATFORM=xcb gazebo One way forward is to force gazebo to use xcb platform. I'll see if there's a way to do that in code so you don't have to use the environment variable.
Created attachment 1673680 [details] QPA workaround
Reported upstream at https://bitbucket.org/osrf/gazebo/issues/2704/gazebo-fails-to-launch-under-wayland I haven't been able to figure out how to override the QPA without an environment variable. We could set the environment variable via the gazebo.desktop launcher, but that would only work when launching gazebo from the GUI, and wouldn't apply when launching from the CLI. Given that the 'gazebo' executable is launching 'gzserver' and 'gzclient' via 'execvp', we can work around the problem by changing the execvp call for 'gzclient' to execvpe, and supply a modified set of environment variables with the QT_QPA_PLATFORM override appended to the existing environment variables. It would let you launch 'gazebo' from the cli and from the gui, but launching 'gzclient' from the cli would still require the QPA override. The attached patch implements this workaround, and works on my machine. It's not great, but I can add it as a workaround for now.
*** This bug has been marked as a duplicate of bug 1816487 ***