stellarium hangs if run in a virtual machine

[gcomes]

I have stellarium installed on linux openSUSE and used by many users. Never had a problem before, up to openSUSE Leap 15.5 (stellarium 1.2) Recently I switched to openSUSE Leap 15.6 (stellarium 23.3) and I started to have problems. First of all, stellarium works on a normal PC with OpenGL 3D acceleration. But if I set LIBGL_ALWAYS_SOFTWARE=1 or I run it in a virtual machine stellarium does not work. What happens is that when I start the program it shows some normal log messages until the line: Using the system_minor.ini file after which all cores shows 100% cpu usage and the program never resumes normal operation. This is essentially the behavior described in issue #3145. I can confirm that the problem starts with commit 7fa8015 (Switch old-style landscape to fragment-shader-based direction computation) and is present in the latest version. I looked more at the problem and found the following: in the file src/core/modules/Landscape.cpp there is (after commit 7fa8015) the following piece of code:

           gl.glEnable(GL_BLEND);
           gl.glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
           if(drawGroundFirst)
                   drawGround(core, firstFreeTexSampler);
           drawDecor(core, firstFreeTexSampler, false);
           if(!drawGroundFirst)
                   drawGround(core, firstFreeTexSampler);

           drawFog(core, firstFreeTexSampler);

The two functions causing problems are: drawGround and drawFog When drawGround is executed, the function call never return, and you can observe the 100% cpu usage on all cores. Instead when drawFog is executed, the function simply never returns. I have commented this two function calls, rebuild stellarium and had it running without problem in a virtual machine (but without ground and fog). It seems like the code in the two functions mentioned has never been tested with mesa software rendering. Can you please have a look at the issue and fix it? It is important to be able to run stellarium in a virtual machine for testing purposes.

[10110111]

and fix it?

Given the symptoms it seems it's Mesa that should fix it. Things work perfectly well (except for performance) for me on Ubuntu 20.04 with Mesa 21.2.6 (on a physical machine).

You may be able to work around this by using --low-graphics command-line option.

[gcomes]

and fix it?

Given the symptoms it seems it's Mesa that should fix it. Things work perfectly well (except for performance) for me on Ubuntu 20.04 with Mesa 21.2.6 (on a physical machine).

You may be able to work around this by using --low-graphics command-line option.

The option --low-graphics does not help. But after the suggestion that the problem was related to mesa, I went back to openSUSE Leap 15.4 (mesa 21.2.4) and compiled stellarium 23.3. Indeed it works in the virtual machine. The problem appears with mesa 21.3.0 and later. So, to trigger the bug you need: stellarium 23.1 or newer, mesa 21.3 or newer, software rendering. I'm submitting a bug report to mesa and see what they says.

[10110111]

You may want to try a newer Mesa as well. Current version is 24.1.2.

[gcomes]

I already did. On openSUSE tumbleweed. It doesn't work.

[gcomes]

To the stellarium developers: please follow the discussion about this issue here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11409. Mesa developers are asking questions (anisotropic filtering) which I'm not qualified to answer.