OpenImageIO.dll can freeze at app exit
Closed this issue · 9 comments
Problem
OpenImageIO.dll freezes on some Windows 7 machines at application exit.
I've debug this issue and it freezes in thread.cpp at line 205:
this->cv.notify_all(); // stop all waiting threads
- It is not freezing when the threads attribute is set to 1
- There is no problem running the same code on Windows 10
- There is also no problem using a static version of the OIIO library
The problem is similar to:
https://social.msdn.microsoft.com/Forums/en-US/7f91e360-2108-40ca-8728-e295f17cb26b/visual-c-2015-stdconditionvariablenotifyall-may-get-stuck?forum=vcgeneral
It can be related to: #1572
Expected behavior:
Providing public Initialise/DeInitialise functions could be a stable solution.
Versions
- OIIO branch/version: 1.8.5 (last stable) - DLL library
- OS: Windows 7 x64
- C++ compiler: Visual Studio 2017 x64
any news on this one?
I had to revert to using OIIO 1.7.17 to build Natron binaries for Windows (Linux and macOS builds use 1.8.8)
We have the same issue in AliceVision/Meshroom. Is it something that can be addressed in OpenImageIO?
Or is there a way to avoid the problem in our usage of the library?
@fabiencastan did you try OIIO::attribute ("threads", 1); as in LuxCoreRender/LuxCore@607bfc9 ?
@devernay Where can I apply this work around in AliceVision/Meshroom? Any hint?
At app startup, but it will turn off all multithreading in OIIO - significantly decrease performance in ImageAlgo for example...
Better workaround is IMHO using a static version of the library...
Need to test if the problem still exists after the merge of #2013.
After running some tests, #2013 does not fix the problem. If the thread pool is not empty when getting to DLL unloading,
this->cv.notify_all();will hang.
In #2038, DLL unloading is detected and the unnecessary/unsafe call to notify_all() is skipped.
@yann-lty I built your modified oiio, and the problem seems solved! Thanks for you work!
I can confirm, that it has been resolved (1.8.16)