[Windows] Deadlock when enabling a device when none was there

[FilippoLeon]

I have a reproducible thread deadlock with the following steps:

• disable all devices in windows control panel
• start the application, create a AL context and a device
• play some audio
• enable one device
• create a new openal context and device

Am I doing something illegal?

One thread is stuck at std::unique_lock lock{mMsgQueueLock}; in popMessage from wasapi.cpp

The other one is waiting at if(DeviceRef dev{VerifyDevice(Device)}) specifically: std::lock_guard _{ListLock}; in alc.cpp

One thread is also stuck in EventThread at line context->mEventSem.wait(); but I do not think thisis an issue

This happens on openal-soft 1.22-2.

Any idea what it could be?

I will try to produce a minimal example.

[FilippoLeon]

So I wanted to test with master and the problem appear to be fixed by adc4574c1ebb65fee981e9d3b3612386893d9c29 (by shear coincidence)

I discovered this after bisecting until that point after discovering that master did, in fact work :).

Can someone explain a bit more in detail the commit?

EDIT: turns out is the missing EHsc that solves the problem

[kcat]

That's odd. If no audio devices are enabled in Windows, I wouldn't expect alcOpenDevice to succeed in the first place. What device is it opening?

I suppose if there's an exception being thrown due to the lack of available devices or something, some locks may not have been getting unlocked properly (MSVC apparently defaults to broken C++ exceptions, necessitating the project explicitly build with the /EHsc, /EHs, or /EHa compiler flag to avoid potential missed object cleanup, leaks, and other fun UB stuff). Which that commit fixes by explicitly specifying /EHsc (the recommended: don't catch asynchronous exceptions (SEH) with C++'s catch(...) blocks, and assume extern "C" functions won't throw C++ exceptions).