[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_lockstd::mutex lock{mMsgQueueLock};
in popMessage from wasapi.cpp

The other one is waiting at
if(DeviceRef dev{VerifyDevice(Device)})
specifically:
std::lock_guardstd::recursive_mutex _{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 adc4574 (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).