Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

OpenImageIO.dll can freeze at app exit #1795

Closed
zavinator opened this issue Oct 26, 2017 · 9 comments
Closed

OpenImageIO.dll can freeze at app exit #1795

zavinator opened this issue Oct 26, 2017 · 9 comments

Comments

@zavinator
Copy link

zavinator commented Oct 26, 2017 •
edited
Loading

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
@zavinator zavinator changed the title OpenImageIO.dll freeze at app exit OpenImageIO.dll freezes at app exit Oct 26, 2017
@zavinator zavinator changed the title OpenImageIO.dll freezes at app exit OpenImageIO.dll can freeze at app exit Oct 26, 2017
@devernay
Copy link
Contributor

devernay commented Feb 20, 2018 •
edited
Loading

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)

@devernay devernay mentioned this issue Feb 20, 2018
Closed
This was referenced Apr 30, 2018
Merged
Closed
@Dade916 Dade916 mentioned this issue May 27, 2018
Merged
devernay added a commit to NatronGitHub/openfx-io that referenced this issue Jul 5, 2018
@devernay
workaround for OIIO bug
2ba9f21 
AcademySoftwareFoundation/OpenImageIO#1795
@ThiagoIze ThiagoIze mentioned this issue Aug 2, 2018
Closed
@yann-lty yann-lty mentioned this issue Sep 4, 2018
Closed
@fabiencastan
Copy link
Contributor

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?

@devernay
Copy link
Contributor

devernay commented Sep 4, 2018

@fabiencastan did you try OIIO::attribute ("threads", 1); as in LuxCoreRender/LuxCore@607bfc9 ?

@richard-bmc
Copy link

@devernay Where can I apply this work around in AliceVision/Meshroom? Any hint?

@zavinator
Copy link
Author

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...

@fabiencastan
Copy link
Contributor

Need to test if the problem still exists after the merge of #2013.

@yann-lty yann-lty mentioned this issue Oct 24, 2018
Merged
5 tasks
@yann-lty
Copy link
Contributor

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.

@richard-bmc
Copy link

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!

@zavinator
Copy link
Author

zavinator commented Nov 8, 2018 •
edited
Loading

I can confirm, that it has been resolved (1.8.16)

@devernay devernay mentioned this issue May 20, 2019
Closed
GerHobbelt pushed a commit to GerHobbelt/oiio that referenced this issue Dec 10, 2024
@cedrik-fuoco-adsk
Adsk contrib - Fix for dependencies workflow (AcademySoftwareFoundati…
01f2175 
…on#1795)

* Tentative fix for macos failure

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* checking for llvm@15 instead as that version is installed by homebrew in the runner

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Trying to trigger the dependencies workflow by making a temporary changes in it.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Using same version of compiler as LLVM_ROOT when building OSL

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adding LLVM_ROOT for macOS only and testing the usage of "llvm" only instead of llvm@15.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Changing back to llvm@15

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* last test to confirm

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* removing temporary change in dependencies_workflow

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

---------

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@fabiencastan @yann-lty @devernay @richard-bmc @zavinator