From f60205ab5063596444a75f32ec065be825547e89 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Aras=20Pranckevi=C4=8Dius?= Date: Fri, 7 Oct 2022 22:15:23 +0300 Subject: [PATCH] oiiotool: work around static destruction order issue (#3295) (#3591) In some cases (at least on Windows, with static linking) the oiiotool main returns zero, but the full process returns 3 error code due to abort() being called. And that is called because a global shared image cache is already destroyed, but the image references from another global (Oiiotool itself) try to use it, get a call into a "pure virtual function" stub that is put by MSVC C runtime into a destroyed object vtable, and that ends up in an abort(). Work around that by making sure various member variables holding ImageRecRef are cleared before main() finishes and global destructors are called. --- src/oiiotool/oiiotool.cpp | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/oiiotool/oiiotool.cpp b/src/oiiotool/oiiotool.cpp index c3fcc48539..5594847889 100644 --- a/src/oiiotool/oiiotool.cpp +++ b/src/oiiotool/oiiotool.cpp @@ -7018,6 +7018,14 @@ main(int argc, char* argv[]) std::cout << "\n" << ot.imagecache->getstats(2) << "\n"; } + // Release references of images that might hold onto a shared + // image cache. Otherwise they would get released at static destruction + // time, at which point due to undefined destruction order the shared + // cache might be already gone. + ot.curimg = nullptr; + ot.image_stack.clear(); + ot.image_labels.clear(); + // Force the OpenEXR threadpool to shutdown because their destruction // might cause us to hang on Windows when it tries to communicate with // threads that would have already been terminated without releasing any