Opened 7 months ago

Closed 7 months ago

Last modified 7 months ago

#8122 closed defect (invalid)

Multiple uninitialized use on stack in ffmpeg

Reported by: bwang Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug: This bug involved multiple uninitialized use on stack. It is found in git commit: db92a3e4630f21535bc3410165edc626232a802a.

How to reproduce: This bug can only be reproduced when ffmpeg is compiled using clang.

% valgrind ./ffmpeg -threads 1 -i test.input -threads 1 -f null /dev/null

PoC input and output of valgrind are attached.

Attachments (4)

valgrind.error.log (403.0 KB) - added by bwang 7 months ago.
Output of Valgrind
input.10522 (977.0 KB) - added by bwang 7 months ago.
PoC input to trigger the bug
valgrind.debug.error.log (333.3 KB) - added by bwang 7 months ago.
Valgrind output with debug information
valgrind-no-hide-banner.debug.error.log (327.6 KB) - added by bwang 7 months ago.
Valgrind report without --hide_banner

Download all attachments as: .zip

Change History (14)

Changed 7 months ago by bwang

Output of Valgrind

Changed 7 months ago by bwang

PoC input to trigger the bug

comment:1 follow-up: Changed 7 months ago by heleppkes

Your binary doesn't have debug symbols, making the valgrind log practically useless. I suggest to re-run it with ffmpeg_g, which is the unstripped version with debug information.

Changed 7 months ago by bwang

Valgrind output with debug information

comment:2 in reply to: ↑ 1 Changed 7 months ago by bwang

Replying to heleppkes:

Your binary doesn't have debug symbols, making the valgrind log practically useless. I suggest to re-run it with ffmpeg_g, which is the unstripped version with debug information.

I have rerun it with the debug version and attached the valgrind output.

comment:3 follow-up: Changed 7 months ago by cehoyos

  • Resolution set to invalid
  • Status changed from new to closed

Please understand that bug-reports with -hide_banner are invalid unless you want to report an issue with that option / I cannot reproduce.

comment:4 in reply to: ↑ 3 ; follow-up: Changed 7 months ago by bwang

Replying to cehoyos:

Please understand that bug-reports with -hide_banner are invalid unless you want to report an issue with that option / I cannot reproduce.

I tried to run the program without -hide_banner, Valgrind can still report the bug.

Are you using gcc to compile ffmpeg? This bug is only reproducible using clang.

comment:5 follow-up: Changed 7 months ago by jamrial

Wouldn't that hint at a bug in clang, and not ffmpeg?

I tried git head using gcc 9.1 on linux x86_64, and indeed can't reproduce this.

comment:6 in reply to: ↑ 5 Changed 7 months ago by bwang

Replying to jamrial:

Wouldn't that hint at a bug in clang, and not ffmpeg?

I tried git head using gcc 9.1 on linux x86_64, and indeed can't reproduce this.

I reported this bug first in ffmpeg because I think maybe there are some undefined behaviors or optimizations that trigger this difference between gcc and clang.

Is that possible that anyone can give me more details of this bug? Then maybe we can decide whether it is a compiler bug or there are some undefined behaviors in ffmpeg.

comment:7 in reply to: ↑ 4 ; follow-up: Changed 7 months ago by cehoyos

Replying to bwang:

Replying to cehoyos:

Please understand that bug-reports with -hide_banner are invalid unless you want to report an issue with that option / I cannot reproduce.

I tried to run the program without -hide_banner, Valgrind can still report the bug.

Any particular reason why you don't want to share the report with us?

comment:8 follow-up: Changed 7 months ago by jamrial

How could we give you information about something we can't even reproduce?

By using -hide_banner your log file is missing vital information like compiler version, so anyone that could attempt to reproduce this with the same Clang toolchain you're using can't because we don't know what version you're using.

comment:9 in reply to: ↑ 7 Changed 7 months ago by bwang

Replying to cehoyos:

Replying to bwang:

Replying to cehoyos:

Please understand that bug-reports with -hide_banner are invalid unless you want to report an issue with that option / I cannot reproduce.

I tried to run the program without -hide_banner, Valgrind can still report the bug.

Any particular reason why you don't want to share the report with us?

Sorry, I just attached the reported generated by Valgrind without -hide_banner.

Changed 7 months ago by bwang

Valgrind report without --hide_banner

comment:10 in reply to: ↑ 8 Changed 7 months ago by bwang

Replying to jamrial:

How could we give you information about something we can't even reproduce?

By using -hide_banner your log file is missing vital information like compiler version, so anyone that could attempt to reproduce this with the same Clang toolchain you're using can't because we don't know what version you're using.

Below is the output generated by ffmpeg without -hide_banner:
ffmpeg version N-94793-gdb92a3e463 Copyright (c) 2000-2019 the FFmpeg developers

built with clang version 7.0.0-3 (tags/RELEASE_700/final)
configuration: --cc=clang
libavutil 56. 35.100 / 56. 35.100
libavcodec 58. 56.101 / 58. 56.101
libavformat 58. 32.104 / 58. 32.104
libavdevice 58. 9.100 / 58. 9.100
libavfilter 7. 58.102 / 7. 58.102
libswscale 5. 6.100 / 5. 6.100
libswresample 3. 6.100 / 3. 6.100

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/home/bwang/Bowen/gitrepo/buddy-test-results/ffmpeg-09052017/monitor_out/input.10522':

Metadata:

major_brand : mp42
minor_version : 1
compatible_brands: isommp42dash
creation_time : 2010-06-19T19:20:15.000000Z

Duration: 00:00:32.90, start: 0.000000, bitrate: 243 kb/s

Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 320x180, 205 kb/s, 25 fps, 25 tbr, 25 tbn, 50 tbc (default)
Metadata:

creation_time : 1970-01-01T00:00:00.000000Z
handler_name : VideoHandler?

Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 16000 Hz, mono, fltp, 27 kb/s (default)
Metadata:

creation_time : 1970-01-01T00:00:00.000000Z
handler_name : SoundHandler?

Stream mapping:

Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native))
Stream #0:1 -> #0:1 (aac (native) -> pcm_s16le (native))

Press [q] to stop, ? for help
Output #0, null, to '/dev/null':

Metadata:

major_brand : mp42
minor_version : 1
compatible_brands: isommp42dash
encoder : Lavf58.32.104
Stream #0:0(eng): Video: wrapped_avframe, yuv420p(progressive), 320x180, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc (default)
Metadata:

creation_time : 1970-01-01T00:00:00.000000Z
handler_name : VideoHandler?
encoder : Lavc58.56.101 wrapped_avframe

Stream #0:1(eng): Audio: pcm_s16le, 16000 Hz, mono, s16, 256 kb/s (default)
Metadata:

creation_time : 1970-01-01T00:00:00.000000Z
handler_name : SoundHandler?
encoder : Lavc58.56.101 pcm_s16le

frame= 812 fps= 91 q=-0.0 Lsize=N/A time=00:00:32.89 bitrate=N/A speed=3.69x
video:425kB audio:1026kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

Note: See TracTickets for help on using tickets.