Multiple uninitialized use on stack in ffmpeg

[Bowen Wang]

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.

[Bowen Wang]

Output of Valgrind

[Bowen Wang]

PoC input to trigger the bug

[Hendrik]

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.

[Bowen Wang]

Valgrind output with debug information

[Bowen Wang]

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.

[Carl Eugen Hoyos]

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

[Bowen Wang]

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.

[James]

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.

[Bowen Wang]

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.

[Carl Eugen Hoyos]

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?

[James]

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.

[Bowen Wang]

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.

[Bowen Wang]

Valgrind report without --hide_banner

[Bowen Wang]

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