#11152: drawtext filter crashes on deallocating font face
-------------------------------------+-------------------------------------
Reporter: Leandro | Owner: (none)
Santiago |
Type: defect | Status: new
Priority: important | Component: avfilter
Version: git-master | Resolution:
Keywords: drawtext | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Description changed by Leandro Santiago:
Old description:
> 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.
>
> I could reproduce it with 7.0 and 7.0.2 tags too.
>
> 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
> =================================================================
> ==803571==ERROR: AddressSanitizer: SEGV on unknown address (pc
> 0x797ba9347141 bp 0x797a845ff800 sp 0x797a845ff7c8 T209153)
> ==803571==The signal is caused by a READ memory access.
> ==803571==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.
> AddressSanitizer:DEADLYSIGNAL
> #0 0x797ba9347141 in FT_List_Find (/usr/lib/libfreetype.so.6+0x10141)
> (BuildId: 732ce343af30b9b1537d9a341a0589ceb564eb27)
> #1 0x797ba93478cd in FT_Done_Face (/usr/lib/libfreetype.so.6+0x108cd)
> (BuildId: 732ce343af30b9b1537d9a341a0589ceb564eb27)
> #2 0x797ba7fbc7a9 in _hb_ft_face_destroy
> /usr/src/debug/harfbuzz/build/../harfbuzz/src/hb-ft.cc:125:16
> #3 0x797ba7fbc7a9 in _hb_ft_font_destroy
> /usr/src/debug/harfbuzz/build/../harfbuzz/src/hb-ft.cc:134:25
> #4 0x797ba7f35d7f in hb_font_destroy
> /usr/src/debug/harfbuzz/build/../harfbuzz/src/hb-font.cc:1992:19
> #5 0x797ba7f35d7f in hb_font_destroy
> /usr/src/debug/harfbuzz/build/../harfbuzz/src/hb-font.cc:1985:1
> #6 0x797baae974db
> (/home/tenchi/projects/ffmpeg_experiments/deps/lib/libavfilter.so.10+0x974db)
> (BuildId: e01c777ecdd5751cc315d0c9e9a92d0f7bc64d21)
> #7 0x797baaff48b2
> (/home/tenchi/projects/ffmpeg_experiments/deps/lib/libavfilter.so.10+0x1f48b2)
> (BuildId: e01c777ecdd5751cc315d0c9e9a92d0f7bc64d21)
> #8 0x797baaf445ea
> (/home/tenchi/projects/ffmpeg_experiments/deps/lib/libavfilter.so.10+0x1445ea)
> (BuildId: e01c777ecdd5751cc315d0c9e9a92d0f7bc64d21)
> #9 0x797baaf48354
> (/home/tenchi/projects/ffmpeg_experiments/deps/lib/libavfilter.so.10+0x148354)
> (BuildId: e01c777ecdd5751cc315d0c9e9a92d0f7bc64d21)
> #10 0x61656eaba507 in execute
> /home/tenchi/projects/ffmpeg_experiments/decode_filter_video.c:269:27
> #11 0x61656e9ad83d in asan_thread_start(void*)
> asan_interceptors.cpp.o
> #12 0x797ba80a339c (/usr/lib/libc.so.6+0x9439c) (BuildId:
> 3de7fd3e8d993406afdcb908e63b88f2f4effea9)
> #13 0x797ba812849b (/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 T209153 created by T0 here:
> #0 0x61656ea68f63 in pthread_create
> (/mnt/evo/tenchi/projects/ffmpeg_experiments/decode_filter_video+0x10ff63)
> (BuildId: 285b2a408601f3235712ef5c690b89ccfc41b779)
> #1 0x61656eab9ec6 in main
> /home/tenchi/projects/ffmpeg_experiments/decode_filter_video.c:197:16
> #2 0x797ba8034e07 (/usr/lib/libc.so.6+0x25e07) (BuildId:
> 3de7fd3e8d993406afdcb908e63b88f2f4effea9)
> #3 0x797ba8034ecb in __libc_start_main (/usr/lib/libc.so.6+0x25ecb)
> (BuildId: 3de7fd3e8d993406afdcb908e63b88f2f4effea9)
> #4 0x61656e9852a4 in _start
> (/mnt/evo/tenchi/projects/ffmpeg_experiments/decode_filter_video+0x2c2a4)
> (BuildId: 285b2a408601f3235712ef5c690b89ccfc41b779)
>
> ==803571==ABORTING
> LD_LIBRARY_PATH=$PWD/deps/lib ./decode_filter_video 17.25s user 157.87s
> system 309% cpu 56.575 total
> }}}
New description:
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
}}}
--
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11152#comment:4>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".
