VGLrun unable to run LWJGL3 applications in Xvfb, Xvnc, & XDummy

[TheUnknownWind]

Attempting to run the demo from: LWJGL3-demos with vglrun -nodl in a XVnc session, or via xpra with xvfb or Xdummy the following error occurs:

X Error of failed request:  BadRequest (invalid request code or no such operation)
  Major opcode of failed request:  151 ()
  Minor opcode of failed request:  0
  Serial number of failed request:  102
  Current serial number in output stream:  102

Running with java 11 vglrun for other applications works i.e. glxgears, glxspheres, blender, etc.

[dcommander]

Why are you passing -nodl to vglrun? Have you tried removing that argument? If memory serves, LWJGL uses dlopen() to load libGL, in which case -nodl will break it. There are a scant few applications that require -nodl, but it should not be used unless it is explicitly recommended for a specific application.

[dcommander]

Confirmed that LWJGL3-demos works properly without -nodl but -nodl produces the error above. Closing.

[TheUnknownWind]

When running lwjgl-demo with vglrun no -nodl the following error occurs:

[VGL] ERROR: Could not load GLX/OpenGL functions
[VGL]    /usr/lib64/libvglfaker.so: undefined symbol: glXGetProcAddressARB

The only way I could find to remove that error was with -nodl & with LD_PRELOAD=libvglfaker-nodl.so or some variety of the latter e.g. LD_PRELOAD="${LD_PRELOAD#libdlfaker.so:libvglfaker-nodl.so:}:libdlfaker.so:libvglfaker-nodl.so

The lwjgl-demo works without vglrun in a XVnc, xvfb & Xdummy session

If you would like any other information please let me know

[TheUnknownWind]

Oh, sorry, I somehow didn't see your second comment. I will try to sort out what on my system is misconfigured as it still doesn't work on my system. Thank you for checking it.

[dcommander]

When running lwjgl-demo with vglrun no -nodl the following error occurs:

[VGL] ERROR: Could not load GLX/OpenGL functions
[VGL]    /usr/lib64/libvglfaker.so: undefined symbol: glXGetProcAddressARB

The only way I could find to remove that error was with -nodl & with LD_PRELOAD=libvglfaker-nodl.so or some variety of the latter e.g. LD_PRELOAD="${LD_PRELOAD#libdlfaker.so:libvglfaker-nodl.so:}:libdlfaker.so:libvglfaker-nodl.so

Which GPU and driver are you using? I was testing with the nVidia proprietary drivers, which do not exhibit the issue. The specific error you're seeing occurs here: https://github.com/VirtualGL/virtualgl/blob/master/server/faker-sym.cpp#L130 I have seen it before, and there are generally two causes:

1. The GPU driver's implementation of libGL does not expose glXGetProcAddress() or glXGetProcAddressARB() for some reason. That was the case "back in the day" with some early broken GPU drivers, but I haven't seen it recently. Also, if that were the cause, I would expect other applications, such as GLXspheres, to fail similarly.
2. One of the application's/framework's shared libraries was linked with an rpath of $ORIGIN. This would normally have the same effect as adding the application's/framework's shared library path to LD_LIBRARY_PATH, but when running with VirtualGL, $ORIGIN resolves to the directory containing libdlfaker.so. Thus, if the application or framework requires any shared libraries that aren't in the default shared library search path, you may see issues like these when running the application/framework with VGL. The workaround is to explicitly add the application's/framework's shared library path to LD_LIBRARY_PATH (most easily accomplished using the -ld option to vglrun.)

The lwjgl-demo works without vglrun in a XVnc, xvfb & Xdummy session

Right, but it isn't GPU-accelerated in that case. It's just using Mesa.

[TheUnknownWind]

Thank you very much for your quick response. the -ld option passing /usr/lib64/ to vglrun for the lwjgl-demo allowed it to run properly.

[dcommander]

That's very odd. Is /usr/lib64 not in the default shared library search path for your system?

[TheUnknownWind]

The path was for /usr/lib64 was configured in /etc/ld.so.conf, rather than being exported in LD_LIBRARY_PATH

If LD_LIBRARY_PATH is set however manually i.e. preceding vglrun or vglrun is run with -ld it runs the lwjgl demo just fine.

[dcommander]

Very weird. My system also has /usr/lib64 in /etc/ld.so.conf, but it works fine without vglrun -ld. It would be nice to understand the difference, but I'm glad you were able to make it work regardless.

[TheUnknownWind]

I should have some time this weekend to poke around with it, would you like me to post my findings if I have any this weekend?

[dcommander]

Yes, please