Dirk Farin

Static object initialization should be thread safe according to https://stackoverflow.com/questions/8102125/is-local-static-variable-initialization-thread-safe-in-c11 A mutex in a global variable as you propose is known to cause problems if a library X calls libheif...

> It seems quite likely that disabling ENABLE_MULTITHREADING_SUPPORT will cause the crash to go away (and I will try that). The concern is if this issue might occur later while...

In your stack trace, I see that `Magick::MagickCleanUp::~MagickCleanUp()` is called from `__run_exit_handlers`. Thus, it seems that the `MagickCleanUp` object is a global static object. Its destructor calls `heif_deinit()`, but at...

libheif has some global variables like the mutex for making it multi-threading safe or the list of loaded plugins. It is not possible to control which global variables are destroyed...

> A static variable only needs to be reset set from True to False(0) right before libheif destroys itself. This does not work because it is not libheif that is...

> According to [OSS-Fuzz Build Status](https://oss-fuzz-build-logs.storage.googleapis.com/index.html#libheif) , libheif's oss-fuzz builds have been failing since September 23rd. Thanks for letting me know. I was not aware of that. The above change...

There is also a `LLVMFuzzerInitialize()` callback for global initializations.

This is how `heif_dec.cc` is doing it: ````c++ class LibHeifInitializer { public: LibHeifInitializer() { heif_init(nullptr); } ~LibHeifInitializer() { heif_deinit(); } }; int main(int argc, char** argv) { // This takes...

You can also omit all `heif_init()` and `heif_deinit()`. It will then auto-initialize and the memory will be freed at program end anyway. Just ignore the reported "memory leaks".

> FYI, you claimed that the crash is due to a de-initialized mutex, but that is not what I see. In the latest stack trace I posted, the crash occurs...