Opened 6 years ago

Closed 6 years ago

#185 closed defect (fixed)

ffmpeg segfaults with large ogg/vorbis files

Reported by: Philius Owned by:
Priority: important Component: avformat
Version: git-master Keywords: segfault ogg/vorbis
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

I've got a 2.7GB ogg/vorbis file I want to convert to an AVI.
I recorded it with cheese.
I built a debugging version of ffmpeg 0.6.1 and ran it under kdbg to track it down.
The problem is in oggdec.c line 282.
It's trying to double the buffer size and that allocation fails, but this isn't checked.

I think mmap() is the only way to go with such large files.
Question: can ffmpeg or some other program split up a large file before processing?
ffmpeg would need to be aware of this for two-pass processing.
I downloaded ffmpeg-0.7-rc1 and the problem in oggdec.c is still there.

Attachments (4)

gdb.txt (12.6 KB) - added by Philius 6 years ago.
gdb session
0001-mem-prefer-SIZE_MAX-over-INT_MAX-in-av_malloc-and-av.patch (1021 bytes) - added by saste 6 years ago.
0002-oggdec-add-integer-overflow-and-allocation-check-in-.patch (1.0 KB) - added by saste 6 years ago.
1st2MB.ogv (2.0 MB) - added by Philius 6 years ago.
First 2MB of 2.5GB ogv

Change History (16)

comment:1 Changed 6 years ago by cehoyos

  • Priority changed from normal to important
  • Status changed from new to open
  • Version changed from unspecified to git-master

Please try latest git master and provide the complete output and backtrace etc. when you observe the crash as explained on http://ffmpeg.org/bugreports.html

Changed 6 years ago by Philius

gdb session

comment:2 Changed 6 years ago by Philius

Done.

Since the problem was inside memcpy.c, the disassembly wouldn't be useful, but for future reference,
what does "disass $pc-32 $pc+32" mean? gdb didn't understand it.

comment:3 Changed 6 years ago by saste

Please try latest git with the attached patches 0001 and 0002.

For applying the patches:
git am PATCH

then configure+make+test.

comment:4 Changed 6 years ago by Philius

I did a

git pull -a

Then I downloaded the patches into a "patches" sibling directory and then did

cat ../patches/*.patch | git-am

and re-ran configure.
I got the following error

ERROR: libx264 version must be >= 0.115.

I had a look at wheezy's repos and libx264 only goes up to 112, so it's a no-go on Debian for the
moment.

I recorded the "problem" video using cheese - about 49 minutes @ 640x480, video 30Hz
, audio 1 channel @ 44,100KHz, which came to 2.5GB.
I ended up splitting the conversion run into 30 mins + 19 mins and joining the two avi's, dropping the
audio and rotating 180 degrees - I recorded myself solving a sudoku puzzle in real-time to try to
capture the stream-of-consciousness involved, so small flurries of activity in a mostly static frame.

The video info claims 30fps but it looks more like 2-3 fps which may be because of disk/cpu
bottle-necking + small variations in lighting conditions affecting overall illumination, if that helps.

The resulting AVIs have visible tinges of green(top) + pink(bottom) which aren't present in the
original, with -sameq(246MB) and hqdn(73MB).

comment:5 Changed 6 years ago by cehoyos

You do not need x264 to test Stefano's patches.

comment:6 Changed 6 years ago by Philius

Done.

I recently upgraded the kernel to 2.6.38-2-amd64 because it looked like my swap space wasn't being used.

It's being used now.

The conversion used all 3GB of my physical memory plus another 3.4GB of swap to complete.
Those green/pink tinges are no longer there.

comment:7 Changed 6 years ago by Philius

The final output after

ffmpeg -i sudoku-0.7.1-ud.avi -vf "hflip,vflip,hqdn3d" sudoku-0.7.1.avi

came to 58.2MB.

comment:8 Changed 6 years ago by saste

Back to the original issue, can you confirm that patch 0002 fixes the reported crash?

You don't need libx264, filters or other stuff, for testing it, try the simplest possible command.

comment:9 Changed 6 years ago by Philius

Huh? To summarize comments (4) through (7),

  1. I applied the two patches on a freshly git-pulled repo (4)
  2. got stuck with x264 (4)
  3. was informed it wasn't needed for the test (5)
  4. proceeded with the build/test (6)
  5. it uses a lot of memory, but works (6)
  6. it results in a smaller and better quality AVI(6,7)

Regards,
Philip

comment:10 Changed 6 years ago by michael

Please upload the first 2mb of the ogg file

Changed 6 years ago by Philius

First 2MB of 2.5GB ogv

comment:11 Changed 6 years ago by Philius

Please find attached the output of

dd if=2011-05-10-021123.ogv of=1st2MB.ogv bs=1M count=2

Philip

comment:12 Changed 6 years ago by michael

  • Reproduced by developer set
  • Resolution set to fixed
  • Status changed from open to closed
Note: See TracTickets for help on using tickets.