ffmpegfs
crashes with free(): invalid next size (normal)
on corrupt media files.
#96
Labels
ffmpegfs
crashes with free(): invalid next size (normal)
on corrupt media files.
#96
I have some media files in my library which are problematic (might be damaged).
ffmpegfs
crashes on some. However, it should not crash but continue to work (it could give a read error on the problematic file, but not terminate completely).I have dug down one example.
The crashes were observed with stable release 2.6, the following reports are now done with latest git checkout from 2021-11-03, latest git commit hash:
8bf2856f
,ffmpegfs --version
:I have compiled
ffmpegfs
with debugging information.I mount my media library with the following command:
ffmpegfs -o allow_other,ro --max_threads=1 --desttype=MP3 --autocopy=MATCH --profile=FF --level=STANDARD --hwaccel_enc=VAAPI --hwaccel_dec=VAAPI -f -d /home/music /mnt/ffmpegfs/music/
There I have a problematic file, called
problematic-file.mp4
. It is audio only.mediainfo problematic-file.mp4
for the original file:ffprobe problematic-file.mp4
for the original file:Playback of the original file is corrupt; I hear quick clicking noise. Terminal output of
ffplay problematic-file.mp4
for the problematic file:Now, I try to read that file from within the
ffmpegfs
mount. As soon as I do that (e.g. bymediainfo /mnt/ffmpegfs/music/problematic-file.mp4.mp3
), theffmpegfs
process aborts withThe complete terminal output of the
ffmpegfs
-command from start to abortion is attached [→ here], snippets of the output are the following:Now, a run of the above
ffmpegfs
call within GDB:gdb ffmpegfs
, on the prompt:run -o allow_other,ro --max_threads=1 --desttype=MP3 --autocopy=MATCH --profile=FF --level=STANDARD --hwaccel_enc=VAAPI --hwaccel_dec=VAAPI -f -d /home/music /mnt/ffmpegfs/music/
to startffmpegfs
with the specified options.Then I read the problematic file. Output is:
On the
(gdb)
propt, typingbt
for "backtrace":On the
(gdb)
prompt, typingcont
for "continue":I don't know how I can legally provide the problematic audio file itself; it still might contain copyrighted material. Do you have an idea? (Do you need it at all to investigate the issue?)
ffplay
itself does not crash on the problematic audio file.A manual run of
ffmpeg -i problematic-file.mp4 -c mp3 foo.mp3
results in an abortion which seems a sane abortion offfmpeg
and not a crash; full terminal output [→ here], snippets in the following:(Exitcode: 69.)
A manual run of
ffmpeg -i problematic-file.mp4 -c copy foo.mp3
results in the following (full terminal output [→ here], snippets in the following):(Exitcode: 0.)
The text was updated successfully, but these errors were encountered: