Bob Friesenhahn

I have no knowledge of this topic, but Google's AI suggests this: Smart Pointers: Use smart pointers (e.g., std::unique_ptr, std::shared_ptr) to manage the lifetime of dynamically allocated objects. This can...

What you are describing (move everything into LLVMFuzzerTestOneInput()) would result in GraphicsMagick initializing/deinitializing for each test iteration, which would dramatically slow the fuzzing. It also does not solve the problem...

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

I have removed the static MagickCleanup object from Magick++. This should solve the crashing issue with libheif. The outcome from oss-fuzz testing is then unknown. Unfortunately, GraphicsMagick oss-fuzzing builds have...

Libheif's own oss-fuzz build is still failing.

The libheif OSS-Fuzz build is no longer reported as a failed build, but the 'Summary of compiled codecs' and 'Supported formats' shows that the only format supported is 'Uncompressed'. This...

oss-fuzz has now decided that issue 372754149 is closed.

The GraphicsMagick oss-fuzz build is doing much better regarding libheif. I think that currently only one useful dependency is excluded (because a pkg-config file is now missing). Feel free to...

The GraphicsMagick oss-fuzz build does not actually need x265 yet, but I tried to re-add it to the oss-fuzz build while using https://bitbucket.org/multicoreware/x265_git/src/stable/ as the source repository path (as libheif's...

I have verified that GraphicsMagick oss-fuzz builds with everything (including x265) now, using "https://bitbucket.org/multicoreware/x265_git/src/stable/". I am not sure if GraphicsMagick should switch to using "https://bitbucket.org/multicoreware/x265_git/src/master/" since I have little knowledge...