On 03/11/2024 03:37, Zhao Zhili wrote:>> -----Original Message-----
>> From: Frank Plowman <p...@frankplowman.com>
>> Sent: 2024年11月3日 2:03
>> To: Nuo Mi <nuomi2...@gmail.com>; Zhao Zhili
<quinkbl...@foxmail.com>; Michael Niedermayer <mich...@niedermayer.cc>
>> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] fate/vvc: Add a sample
which lose frames before 5c66a3
>>
>> Hi,
>>
>> No, it doesn't seem so. I tried decoding the file with combinations of:
>>
>> * Reverting 5c66a3ab51807b0f471822ae261dd6b09030a439
>> * My AV_CEIL_RSHIFT patch
>> * My subpicture validation patch
>> * Your fuzz fixes
>>
>> and only those combinations where I did not revert 5c66a3a worked, so it
>> seems that is the correct fix.
>
> You mean AV_CEIL_RSHIFT patch, subpicture validation patch and fuzz patch
> together fixed the issue?
No sorry, I mean the only change which has any effect on the issue
appears to be yours. If 5c66a3a is reverted, the sample breaks and if
it is not reverted then the sample works. The other patch(set)s do not
appear to have any effect on this particular issue.
>
>> I do not have an x86-32 machine
>> available to test the issue, but 5c66a3a seems to work fine on x86-64
>> and AArch64.
>
> It's easy to build a x86-32 version of ffmpeg on x86-64. For example,
after
> install gcc-multilib g++-multilib, configure with
> ./configure --arch=x86 --extra-cflags="-m32" --extra-ldflags="-m32"
>
Thank you for this. Here are some further findings related to the issue
which may be of interest:
* The test only fails when FFmpeg is compiled with GCC and not when
FFmpeg is compiled with Clang.
* The test produces an AddressSanitizer error:
=================================================================
==18690==ERROR: AddressSanitizer: stack-use-after-return on address
0xea8cd0ae at pc 0x08497395 bp 0xecc9a658 sp 0xecc9a64c
READ of size 1 at 0xea8cd0ae thread T3 (dec0:0:vvc)
#0 0x8497394 in prepare_intra_edge_params_8
libavcodec/vvc/intra_template.c:570
#1 0x8497394 in intra_pred_8 libavcodec/vvc/intra_template.c:627
#2 0x85506e7 in predict_intra libavcodec/vvc/intra.c:259
#3 0x85506e7 in reconstruct libavcodec/vvc/intra.c:578
#4 0x85506e7 in ff_vvc_reconstruct libavcodec/vvc/intra.c:682
#5 0x84f6ed8 in run_recon libavcodec/vvc/thread.c:518
#6 0x84fe6c6 in task_run_stage libavcodec/vvc/thread.c:648
#7 0x84fe6c6 in task_run libavcodec/vvc/thread.c:675
#8 0x8504f62 in run_one_task libavcodec/executor.c:103
#9 0x8504f62 in ff_executor_execute libavcodec/executor.c:229
#10 0x84f7dd6 in add_task libavcodec/vvc/thread.c:129
#11 0x84f7dd6 in frame_thread_add_score libavcodec/vvc/thread.c:230
#12 0x8500e7b in ff_vvc_frame_submit libavcodec/vvc/thread.c:825
#13 0x842a17c in submit_frame libavcodec/vvc/dec.c:1007
#14 0x842a17c in vvc_decode_frame libavcodec/vvc/dec.c:1070
#15 0x83e5cee in decode_simple_internal libavcodec/decode.c:443
#16 0x83e5cee in decode_simple_receive_frame libavcodec/decode.c:613
#17 0x83e5cee in ff_decode_receive_frame_internal
libavcodec/decode.c:649
#18 0x83e72cd in decode_receive_frame_internal libavcodec/decode.c:666
#19 0x83e83a7 in avcodec_send_packet libavcodec/decode.c:753
#20 0x807c2cc in packet_decode fftools/ffmpeg_dec.c:724
#21 0x807c2cc in decoder_thread fftools/ffmpeg_dec.c:953
#22 0x80f5a25 in task_wrapper fftools/ffmpeg_sched.c:2544
#23 0xf67199bd in asan_thread_start(void*)
(/nix/store/f2hj98sdr409g70wibawhsq4hmv6pxx7-gcc-13.2.0-lib/lib/libasan.so.8+0x419bd)
#24 0xf6291b46 in start_thread
(/nix/store/9rr99432z1cmxk6m81i8qi6g8h8rcr8x-glibc-multi-2.39-5/lib/32/libc.so.6+0x8ab46)
(BuildId: a24160f576613cfe4a2f5da8344c83a3882052be)
#25 0xf6325d57 in __GI___clone3
(/nix/store/9rr99432z1cmxk6m81i8qi6g8h8rcr8x-glibc-multi-2.39-5/lib/32/libc.so.6+0x11ed57)
(BuildId: a24160f576613cfe4a2f5da8344c83a3882052be)
Address 0xea8cd0ae is located in stack of thread T3 (dec0:0:vvc) at
offset 174 in frame
#0 0x8576b4f in abs_get_rice_param libavcodec/vvc/cabac.c:1845
This frame has 1 object(s):
[32, 160) 'rice_params' (line 1848) <== Memory access at offset 174
overflows this variable
HINT: this may be a false positive if your program uses some custom
stack unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
Thread T3 (dec0:0:vvc) created by T0 here:
#0 0xf67198c4 in pthread_create
(/nix/store/f2hj98sdr409g70wibawhsq4hmv6pxx7-gcc-13.2.0-lib/lib/libasan.so.8+0x418c4)
#1 0x80f0672 in task_start fftools/ffmpeg_sched.c:422
SUMMARY: AddressSanitizer: stack-use-after-return
libavcodec/vvc/intra_template.c:570 in prepare_intra_edge_params_8
Shadow bytes around the buggy address:
0xea8cce00: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
0xea8cce80: f5 f5 f5 f5 f5 f5 f5 f5 00 00 00 00 00 00 00 00
0xea8ccf00: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
0xea8ccf80: f5 f5 f5 f5 f5 f5 f5 f5 00 00 00 00 00 00 00 00
0xea8cd000: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
=>0xea8cd080: f5 f5 f5 f5 f5[f5]f5 f5 00 00 00 00 00 00 00 00
0xea8cd100: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
0xea8cd180: f5 f5 f5 f5 f5 f5 f5 f5 00 00 00 00 00 00 00 00
0xea8cd200: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
0xea8cd280: f5 f5 f5 f5 f5 f5 f5 f5 00 00 00 00 00 00 00 00
0xea8cd300: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==18690==ABORTING
* The test does not fail if FFmpeg is configured with --disable-asm
* If 5c66a3a and FFmpeg is compiled for x86-32 using GCC, the test still
fails due to the Address Sanitizier error, and not in the same way as
when compiled for x86-64.
* The patch "x86/vvc: Fix build error for arch x86_32" currently on the
mailing list also does not fix the issue.
I think these findings point to the x86-32-specific issue not actually
being the same issue that is fixed by 5c66a3a, but rather a separate
issue, in the x86 assembly optimisations, which happens to show in the
same sequence. I am not sure exactly what part of the assembly
optimisations could be interacting with intra prediction to cause this.
All the best,
Frank
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
