Lwjgl3: OpenAL AL/ALC extensions should receive fully populated capabilities object

[LAGonauta]

Environment

• LWJGL version: 3.2.2
• LWJGL build #: unknown
• Java version: 1.8.0_261 amd64
• Platform: Windows 10 64-bit
• Module: openal

Description

Calling extension methods will crash the application if pointer checking is enabled and an OpenAL router is being used (instead of the OpenAL driver DLL directly).

This makes it impossible to use OpenAL Soft through a router because AL.createCapabilities calls alcGetThreadContext:
https://github.com/LWJGL/lwjgl3/blob/b07955a2ad8b66deae2b1c5093511d1eb10e7d84/modules/lwjgl/openal/src/main/java/org/lwjgl/openal/AL.java#L218
However alcGetThreadContext does not receive a fully populated ALCCapabilities, it generates a new one that does not use alcGetProcAddress with the correct function pointers:
https://github.com/LWJGL/lwjgl3/blob/5ab5b35ab0cae4116b7bd547d04002ba74d2ff77/modules/lwjgl/openal/src/generated/java/org/lwjgl/openal/EXTThreadLocalContext.java#L47

This pattern is seen in various extensions, and will cause problems when using a router. Extensions should not call getICD, but always receive the fully populated capabilities.

How to reproduce

1. Install OpenAL from https://www.openal.org/downloads/oalinst.zip, System32's OpenAL.dll will be the router for our application.
2. Download OpenAL Soft from https://openal-soft.org/ and copy to System32 as soft_oal.dll
3. Run the following code, setting -Dorg.lwjgl.openal.libname="C:/Windows/System32/OpenAL32.dll"

int deviceId = ALC10.alcOpenDevice("OpenAL Soft");
ALCCapabilities alcCaps = ALC.createCapabilities(deviceId);
ALCapabilities alCaps = AL.createCapabilities(alcCaps); <-- Should throw exception here on line 218 from AL.class

If wrap_oal.dll is installed, the following will work as it does not support EXT_thread_local_context:

int deviceId = ALC10.alcOpenDevice("Generic Software");
ALCCapabilities alcCaps = ALC.createCapabilities(deviceId);
ALCapabilities alCaps = AL.createCapabilities(alcCaps);

[Spasi]

Hey @LAGonauta,

I've been working on this for a while now. Fixing the problem you described was relatively simple, but then I hit a different problem with ALC_EXT_thread_local_context. I would get a properly initialized ALCCapabilities, ALC_EXT_thread_local_context was reported as available and I could call its functions, but alcSetThreadContext always returned false. I had to build a custom OpenAL Soft and a custom router to figure it out:

1. When the router (OpenAL32.dll) from https://www.openal.org/ is used, the ALCcontext handle returned to the client program is actually a wrapped handle. It is not the actual context handle created by the implementation (soft_oal.dll, wrap_oal.dll, etc.). Normally, when an ALC function is called, that handle is unwrapped and forwarded to the implementation. This does not happen when ALC_EXT_thread_local_context functions are called. OpenAL Soft receives the wrapped handle, which it does not recognize, so it sets the error state to ALC_INVALID_CONTEXT and returns without doing anything.

2. When the router from OpenAL Soft is used... we crash on alcOpenDevice. OpenAL Soft's router is still experimental, so I had a look and there was a nested locking bug (had to replace an std::mutex with an std::recursive_mutex). With that fixed, alcSetThreadContext works fine and everything is OK (even with non-OpenAL Soft implementations).

I will push the ALCCapabilities fix when I clean it up, but my recommendation would be: don't use the router, go to the implementation directly. You could search for implementations manually if you have to (look for *oal.dll in the usual paths).

[Spasi]

Thanks @LAGonauta!