Opened 4 years ago
Closed 2 years ago
#8494 closed defect (fixed)
UBSan: outside the range of representable values of type 'long'
Reported by: | andreafioraldi | Owned by: | |
---|---|---|---|
Priority: | minor | Component: | avformat |
Version: | git-master | Keywords: | sbg ubsan |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | yes | |
Analyzed by developer: | no |
Description
Hi, run
ffmpeg -y -i ubsan_sbgdec_200 -c:v mpeg4 -c:a out.mp4
compiled with
-fsanitize=undefined
The output is similar to
ffmpeg version 4.2.2 Copyright (c) 2000-2019 the FFmpeg developers built with clang version 8.0.0-3~ubuntu18.04.2 (tags/RELEASE_800/final) configuration: --cc=clang-8 --cxx=clang++-8 --ld=clang-8 libavutil 56. 31.100 / 56. 31.100 libavcodec 58. 54.100 / 58. 54.100 libavformat 58. 29.100 / 58. 29.100 libavdevice 58. 8.100 / 58. 8.100 libavfilter 7. 57.100 / 7. 57.100 libswscale 5. 5.100 / 5. 5.100 libswresample 3. 5.100 / 3. 5.100 Trailing options were found on the commandline. libavformat/sbgdec.c:200:14: runtime error: 6.66267e+30 is outside the range of representable values of type 'long' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior libavformat/sbgdec.c:200:14 in ubsan_sbgdec_200: Invalid data found when processing input
Seems that, in the str_to_time function of libavformat/sbgdec.c, the line
*rtime = (hours * 3600LL + minutes * 60LL + seconds) * AV_TIME_BASE;
Cause an overflow of the int64_t pointed by rtime.
Attachments (1)
Change History (5)
by , 4 years ago
Attachment: | ubsan_sbgdec_200 added |
---|
comment:1 by , 4 years ago
comment:2 by , 4 years ago
Yes, it is (N-96467-g07b3dbbbb2). I attached the output of 4.2.2 but it is the same for git-master.
comment:3 by , 4 years ago
Keywords: | sbg ubsan added |
---|---|
Reproduced by developer: | set |
Status: | new → open |
comment:4 by , 2 years ago
Resolution: | → fixed |
---|---|
Status: | open → closed |
probably fixed by ac6c8993f79eaefb76e1fdf0eef5373ab3a46a4e
its not reproduceable anymore
Note:
See TracTickets
for help on using tickets.
Is this issue reproducible with current FFmpeg?