Add Github Actions to build and check project #1
Assignees
Comments
MarcAntoine-Arnaud
pushed a commit
that referenced
this issue
Aug 10, 2021
CID 1460603 (#1 of 1): Improper use of negative value (NEGATIVE_RETURNS)
palemieux
pushed a commit
that referenced
this issue
Sep 7, 2021
"frag_start" is redundant, and every occurance can be replaced with cluster[0].dts - start_dts The proof of no behaviour changes: (All line number below is based on commit bff7d66) "frag_start" is read at 4 place (with all possible call stacks): mov_write_packet ... mov_flush_fragment mov_write_moof_tag mov_write_moof_tag_internal mov_write_traf_tag mov_write_tfxd_tag (#1) mov_write_tfdt_tag (#2) mov_add_tfra_entries (#3) mov_write_sidx_tags mov_write_sidx_tag (#4) mov_write_trailer mov_auto_flush_fragment mov_flush_fragment ... (#1 #2 #3 #4) mov_write_sidx_tags mov_write_sidx_tag (#4) shift_data compute_sidx_size get_sidx_size mov_write_sidx_tags mov_write_sidx_tag (#4) All read happens in "mov_write_trailer" and "mov_write_moof_tag". So we need to prove no behaviour change in these two functions. Condition 1: for every track that have "trk->entry == 0", trk->frag_start == trk->track_duration. Condition 2: for every track that have "trk->entry > 0", trk->frag_start == trk->cluster[0].dts - trk->start_dts. Definition 1: "Before flush" means just before the invocation of "mov_flush_fragment", except for the auto-flush case in "mov_write_single_packet", which means before L5934. Lemma 1: If Condition 1 & 2 is true before flush, Condition 1 & 2 is still true after "mov_flush_fragment" returns. Proof: No update to the tracks that have "trk->entry == 0" before flushing, so we only consider tracks that have "trk->entry > 0": Case 1: !moov_written and moov will be written in this iteration trk->entry = 0 L5366 trk->frag_start == trk->cluster[0].dts - trk->start_dts Lemma condition trk->frag_start += trk->start_dts + trk->track_duration - trk->cluster[0].dts; L5363 So trk->entry == 0 && trk->frag_start == trk->track_duration Case 2: !moov_written and moov will NOT be written in this iteration nothing changed Case 3: moov_written trk->entry = 0 L5445 trk->frag_start == trk->cluster[0].dts - trk->start_dts Lemma condition trk->frag_start += trk->start_dts + trk->track_duration - trk->cluster[0].dts; L5444 So trk->entry == 0 && trk->frag_start == trk->track_duration Note that trk->track_duration may be updated for the tracks that have "trk->entry > 0" (mov_write_moov_tag will update track_duration of "tmcd" track, but it must have 1 entry). But in all case, trk->frag_start is also updated to consider the new value. Lemma 2: If Condition 1 & 2 is true before "ff_mov_write_packet" invocation, Condition 1 & 2 is still true after it returns. Proof: Only the track corresponding to the pkt is updated, and no update to relevant variables if trk->entry > 0 before invocation. So we only need to prove "trk->frag_start == trk->cluster[0].dts - trk->start_dts" after trk->entry increase from 0 to 1. Case 1: trk->start_dts == AV_NOPTS_VALUE Case 1.1: trk->frag_discont && use_editlist trk->cluster[0].dts = pkt->dts at L5741 trk->frag_start = pkt->pts at L5785 trk->start_dts = pkt->dts - pkt->pts at L5786 So trk->frag_start == trk->cluster[0].dts - trk->start_dts Case 1.2: trk->frag_discont && !use_editlist trk->cluster[0].dts = pkt->dts at L5741 trk->frag_start = pkt->dts at L5790 trk->start_dts = 0 at L5791 So trk->frag_start == trk->cluster[0].dts - trk->start_dts Case 1.3: !trk->frag_discont trk->cluster[0].dts = pkt->dts at L5741 trk->frag_start = 0 init trk->start_dts = pkt->dts at L5779 So trk->frag_start == trk->cluster[0].dts - trk->start_dts Case 2: trk->start_dts != AV_NOPTS_VALUE Case 2.1: trk->frag_discont trk->cluster[0].dts = pkt->dts at L5741 trk->frag_start = pkt->dts - trk->start_dts at L5763 So trk->frag_start == trk->cluster[0].dts - trk->start_dts Case 2.2: !trk->frag_discont trk->cluster[0].dts = trk->start_dts + trk->track_duration at L5749 trk->track_duration == trk->frag_start Lemma condition So trk->frag_start == trk->cluster[0].dts - trk->start_dts Lemma 3: Condition 1 & 2 is true in all case before and after "ff_mov_write_packet" invocation, before flush and after "mov_flush_fragment" returns. Proof: All updates to relevant variable happen either in "ff_mov_write_packet", or during flush. And Condition 1 & 2 is true initially. So with lemma 1 & 2, we can prove this use induction. Noticed that all read of "frag_start" only happen in "trk->entry > 0" branch. Now we need to prove Condition 2 is true before each read. Because no update to variables relevant to Condition 2 between "before flush" and "mov_write_moof_tag" invocation, we can conclude Condition 2 is true before every invocation of "mov_write_moof_tag". No behaviour change in "mov_write_moof_tag" is proved. In "mov_write_trailer", No update to relevant variables after the last flush and before the invocation of "mov_write_sidx_tag". So no behaviour change to "mov_write_trailer" is proved. Q.E.D. Signed-off-by: Hu Weiwen <[email protected]> Signed-off-by: Martin Storsjö <[email protected]>
palemieux
pushed a commit
that referenced
this issue
Dec 17, 2021
…ion parameter
If memory allocation fails, ERROR(ENOMEM) '-12' will be returned.
When resample() is done first, the negative size param would cause buffer-overflow and SEGV in swri_rematrix().
When swri_rematrix() is run first, resample() would not cause an error but Err num as a wrong parameter passing.
Err num should be returned immediately. And remove an unneeded term from an assert.
coredump info:
#0 0x499517 in posix_memalign (/home/r1/ffmpeg/ffmpeg_4.4.1+0x499517)
#1 0x6c1f0b4 in av_malloc /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavutil/mem.c:86:9
#2 0x6c208fe in av_mallocz /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavutil/mem.c:239:17
#3 0x6c207ad in av_mallocz_array /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavutil/mem.c:195:12
#4 0x654b2e5 in swri_realloc_audio /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libswresample/swresample.c:418:14
#5 0x654f9a1 in swr_convert_internal /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libswresample/swresample.c:601:17
#6 0x654d2c0 in swr_convert /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libswresample/swresample.c:766:19
#7 0x186cf56 in flush_frame /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/af_aresample.c:251:13
#8 0x186a454 in request_frame /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/af_aresample.c:288:20
#9 0x787d9c in ff_request_frame_to_filter /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:459:15
#10 0x7877f1 in forward_status_change /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:1257:19
#11 0x77ed7e in ff_filter_activate_default /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:1288:20
#12 0x77e4e1 in ff_filter_activate /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:1441:11
#13 0x793b3f in ff_filter_graph_run_once /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfiltergraph.c:1403:12
#14 0x7a7bee in get_frame_internal /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/buffersink.c:131:19
#15 0x7a7287 in av_buffersink_get_frame_flags /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/buffersink.c:142:12
#16 0x792888 in avfilter_graph_request_oldest /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfiltergraph.c:1356:17
#17 0x5d07df in transcode_from_filter /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:4639:11
#18 0x59e557 in transcode_step /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:4729:20
#19 0x593970 in transcode /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:4805:15
#20 0x58f7a4 in main /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:5010:9
#21 0x7f6fd2dee0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
SUMMARY: AddressSanitizer: negative-size-param (/home/r1/ffmpeg/ffmpeg_4.4.1+0x497e67) in __asan_memcpy
Reported-by: TOTE Robot <[email protected]>
Signed-off-by: Michael Niedermayer <[email protected]>
palemieux
pushed a commit
that referenced
this issue
Jul 12, 2022
davs2_decoder_close doesn't free those on the fly frames which
don't get output yet. It's a design bug, but easy to workaround.
Before the patch:
Direct leak of 1198606 byte(s) in 2 object(s) allocated from:
#0 0x563af5e1e5f0 in malloc (ffmpeg+0x6675f0)
#1 0x563af9765ef3 in davs2_malloc davs2/source/common/common.h:1240
#2 0x563af9765ef3 in davs2_alloc_picture davs2/source/common/header.cc:815
Indirect leak of 3595818 byte(s) in 6 object(s) allocated from:
#0 0x563af5e1e5f0 in malloc (ffmpeg+0x6675f0)
#1 0x563af9765ef3 in davs2_malloc davs2/source/common/common.h:1240
#2 0x563af9765ef3 in davs2_alloc_picture davs2/source/common/header.cc:815
Signed-off-by: Zhao Zhili <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: