drawtext filter crashes on deallocating font face

[Leandro Santiago]

Summary of the bug:

I have a long-run application using the C API and I noticed that it crashes arbitrarily after some minutes (the exact timing is arbitrary).

The application creates several instances of the drawtext filter, in multiple threads. I don't believe it's a concurrency issue in the application, so I could isolate the problem in a simple C program that depends only on libav* and pthread.

It seems to be caused by a double delete on using freetype.

How to reproduce:

I managed to reproduce the bug by using libavfilter directly. I don't believe it'll work with ffmpeg directly.

I'm sending as attached in this ticket a C program adapted from doc/examples/decode_filter_video.c that launches several threads, each with its own drawtext filter calls.

I noticed that the issue started happening after the commit 1eeb59a2099479eeead8cdc0d4586443fb301a8a that introduces harfbuzz as dependency.

The first release I could reproduce the issue is 6.1.

6.0.1 does not have the issue.

I could reproduce it with 7.0 and 7.0.2 tags too.

Tested harfbuzz versions were 9.0 and 2.7.4. Free type version: 2.13.2.

I could reproduce it on Ubuntu 22.04 amd64 and Manjaro stable (current as on Aug 2024).

In the zipped attachment to this ticket, you can build and run the c program with:

CC=clang-18 make
time ./decode_filter_video

It will take some minutes, and on my example, address sanitizer will indicate the path for the segmentation fault:

$ time LD_LIBRARY_PATH=$PWD/deps/lib ./decode_filter_video                                  
AddressSanitizer:DEADLYSIGNAL
=================================================================
==1797244==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x787157147141 bp 0x7871383ff800 sp 0x7871383ff7c8 T325898)
==1797244==The signal is caused by a READ memory access.
==1797244==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
    #0 0x787157147141 in FT_List_Find (/usr/lib/libfreetype.so.6+0x10141) (BuildId: 732ce343af30b9b1537d9a341a0589ceb564eb27)
    #1 0x7871571478cd in FT_Done_Face (/usr/lib/libfreetype.so.6+0x108cd) (BuildId: 732ce343af30b9b1537d9a341a0589ceb564eb27)
    #2 0x787155dbc7a9 in _hb_ft_face_destroy /usr/src/debug/harfbuzz/build/../harfbuzz/src/hb-ft.cc:125:16
    #3 0x787155dbc7a9 in _hb_ft_font_destroy /usr/src/debug/harfbuzz/build/../harfbuzz/src/hb-ft.cc:134:25
    #4 0x787155d35d7f in hb_font_destroy /usr/src/debug/harfbuzz/build/../harfbuzz/src/hb-font.cc:1992:19
    #5 0x787155d35d7f in hb_font_destroy /usr/src/debug/harfbuzz/build/../harfbuzz/src/hb-font.cc:1985:1
    #6 0x787158c974db in hb_destroy /home/tenchi/projects/ffmpeg/libavfilter/vf_drawtext.c:1385:5
    #7 0x787158c974db in draw_text.isra.0.cold /home/tenchi/projects/ffmpeg/libavfilter/vf_drawtext.c:1822:9
    #8 0x787158df48b2 in filter_frame /home/tenchi/projects/ffmpeg/libavfilter/vf_drawtext.c:1893:9
    #9 0x787158d445ea in ff_filter_frame_framed /home/tenchi/projects/ffmpeg/libavfilter/avfilter.c:1014:11
    #10 0x787158d445ea in ff_filter_frame_to_filter /home/tenchi/projects/ffmpeg/libavfilter/avfilter.c:1167:11
    #11 0x787158d445ea in ff_filter_activate_default /home/tenchi/projects/ffmpeg/libavfilter/avfilter.c:1231:20
    #12 0x787158d445ea in ff_filter_activate /home/tenchi/projects/ffmpeg/libavfilter/avfilter.c:1392:11
    #13 0x787158d48354 in get_frame_internal /home/tenchi/projects/ffmpeg/libavfilter/buffersink.c:111:19
    #14 0x646f9c9dd507 in execute /home/tenchi/projects/ffmpeg_experiments/decode_filter_video.c:269:27
    #15 0x646f9c8d083d in asan_thread_start(void*) asan_interceptors.cpp.o
    #16 0x787155ea339c  (/usr/lib/libc.so.6+0x9439c) (BuildId: 3de7fd3e8d993406afdcb908e63b88f2f4effea9)
    #17 0x787155f2849b  (/usr/lib/libc.so.6+0x11949b) (BuildId: 3de7fd3e8d993406afdcb908e63b88f2f4effea9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/usr/lib/libfreetype.so.6+0x10141) (BuildId: 732ce343af30b9b1537d9a341a0589ceb564eb27) in FT_List_Find
Thread T325898 created by T0 here:
    #0 0x646f9c98bf63 in pthread_create (/mnt/evo/tenchi/projects/ffmpeg_experiments/decode_filter_video+0x10ff63) (BuildId: bfac51cde4af205bf07061797993d788e65b086f)
    #1 0x646f9c9dcec6 in main /home/tenchi/projects/ffmpeg_experiments/decode_filter_video.c:197:16
    #2 0x787155e34e07  (/usr/lib/libc.so.6+0x25e07) (BuildId: 3de7fd3e8d993406afdcb908e63b88f2f4effea9)
    #3 0x787155e34ecb in __libc_start_main (/usr/lib/libc.so.6+0x25ecb) (BuildId: 3de7fd3e8d993406afdcb908e63b88f2f4effea9)
    #4 0x646f9c8a82a4 in _start (/mnt/evo/tenchi/projects/ffmpeg_experiments/decode_filter_video+0x2c2a4) (BuildId: bfac51cde4af205bf07061797993d788e65b086f)

==1797244==ABORTING
LD_LIBRARY_PATH=$PWD/deps/lib ./decode_filter_video  27.44s user 242.96s system 310% cpu 1:27.09 total

[Leandro Santiago]

example of C program that reproduces the issue

[Leandro Santiago]

The earliest release I can reproduce the issue is 6.1, which is when the dependency on harfbuzz was added.

[Leandro Santiago]

I've just re-uploaded the sample C code with updated to work with ffmpeg from master (87068b9600daa522e3f45b5501ecd487a3c0be57).

[Leandro Santiago]

I've provided a fix for the issue in the ffmpeg-devel mailing list, now waiting for review: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-October/335565.html

[Marton Balint]

Applied in 69cbda5770d2fb0d7f11de3a7ba0fea16c6b65b4.