> Maybe your patch to ftfuzzer could be incorporated if controlled by, say, an environment variable or a command line option?

That would probably be a good idea, though I'm not sure what to call such an option nor exactly what it should look like. The issue is that this does two separate things. The first is to ensure there is nothing shared between runs (tying the FT_Library to the stack frame). The second if to force lsan to run each time. Something like 'FT_FUZZER_FULL_ISOLATION' or something might work.

If this were a runtime flag it may be required to dynamically load the lsan symbols (instead of assuming that the user is always running with an lsan build). If this is a compile time flag it might need to be two flags, one for forcing the FT_Library to the stack frame and another for forcing lsan to run each time.

Found with libFuzzer at FreeType 75722f89290eb1cb316cd240763545d7277e0481 , reproduction attached.

An example sort of report for this issue from LeakSanitizer is:

ERROR: LeakSanitizer: detected memory leaks

Direct leak of 30 byte(s) in 5 object(s) allocated from:

__interceptor_malloc llvm_all/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3
ft_mem_qalloc freetype2/src/base/ftutil.c:76:15
ft_mem_alloc freetype2/src/base/ftutil.c:55:0
ft_mem_qrealloc freetype2/src/base/ftutil.c:146:0
ft_mem_realloc freetype2/src/base/ftutil.c:102:13
_bdf_parse_glyphs freetype2/src/bdf/bdflib.c:1680:12
_bdf_readstream freetype2/src/bdf/bdflib.c:790:17
bdf_load_font freetype2/src/bdf/bdflib.c:2472:0
BDF_Face_Init freetype2/src/bdf/bdfdrivr.c:364:0
open_face freetype2/src/base/ftobjs.c:1178:15
FT_Open_Face freetype2/src/base/ftobjs.c:2176:19
FT_New_Memory_Face freetype2/src/base/ftobjs.c:1268:12
LLVMFuzzerTestOneInput freetype2/src/tools/ftfuzzer/ftfuzzer.cc:199:10
FTFuzzer::TargetFunction(unsigned char const*, unsigned long) freetype2/src/tools/ftfuzzer/ftmutator.cc:153:14

Initially this was reported at the end of a fuzzer run, so I ran all of the produced test cases individually, but this did not reproduce (this appears to occur inside already covered code). I then changed ftfuzzer.cc to force lsan to check after each run, which caused runs of the fuzzer to produce crash files of the cases when this is detected. However, these do not by themselves reproduce either. I then applied the attached ftfuzzer.cc.patch to both force lsan checks on each run and also create a new FT_Library each run (both of which I don't recommend generally, it makes things much slower). This causes runs of the fuzzer to produce crash files of the cases when this is detected. This finally produced a reproduction. I'm attaching this ftfuzzer.cc.patch as a local aid in finding actual leak reproductions of this sort, but I do not recommend it for general use.