async await bug with external subtitles

[brabebhin]

hi @lukasf

Just found this bug today, unfortunately, tomorrow is vacation time for 1 week so i don't know if I'll be able to fix it.

1. Run the CS sample, open a video file
2. Attach an external subtitle using ffmpeg (not the windows API) The following error trace will occur:

FFmpegInteropX.dll!std::_Mutex_base::unlock() Line 67 C++ FFmpegInteropX.dll!std::lock_guard::~lock_guard() Line 433 C++ FFmpegInteropX.dll!winrt::FFmpegInteropX::implementation::FFmpegMediaSource::AddExternalSubtitleAsync$_ResumeCoro$1() Line 1279 C++ FFmpegInteropX.dll!std::experimental::coroutine_handle::resume() Line 107 C++ FFmpegInteropX.dll!std::experimental::coroutine_handle::operator()() Line 99 C++ FFmpegInteropX.dll!winrt::impl::resume_apartment_callback(winrt::impl::com_callback_args * args) Line 8813 C++

This seems to be caused by

co_await caller;

line 1277 in FFmpegMediaSource.

I think it may be a compiler bug with the lock_guard not handling the co_await correctly.

[lukasf]

Huh interesting. lock_guard is expected to work with co_await, although it is not recommended for different reasons. Does this happen in the sample app as well? I will look into this when I return from my vacation.

[brabebhin]

Yes. This is going on in the sample.

[brabebhin]

Airplane reading. Yes, lock_guard is a synchronous lock. It most likely won't work properly with co_await. This might cause subtle hidden bugs in prod environments. It is equivalent to use lock statements in async blocks in c#.

We should probably switch to manual mutex lock/unlock for async methods.

It is curious why this reproduces easily for adding subtitles but not for others.