nstockma <[EMAIL PROTECTED]> added the comment:

Here was what I originally tried to submit:

I am trying to transcode from a .mp4 to a .mp3 format. Valgrind reports an
Invalid Read of 4 bytes at an invalid memory location.

The test file can be found inside the .tgz archive at the following link:
http://www.eecs.berkeley.edu/~zhl210/545634-1659-52280140-InvalidRead.tgz

I confirmed that this bug is reproducible on Linux OS, Debian x32 with the
latest subversion of ffmpeg, SVN-r14338.
I used a 32-bit Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz.


To reproduce: 
wget http://www.eecs.berkeley.edu/~zhl210/545634-1659-52280140-InvalidRead.tgz
tar xzfv 545634-1659-52280140-InvalidRead.tgz
valgrind ./ffmpeg_g -i ../Desktop/1659-m_cut.3.mp4 ../Desktop/1659-m_cut.3.mp3
(<---- depending on where you've unzipped the .tgz file of course)

Note that this bug does not cause a crash so I have not included a gdb
backtrace, but please let me know if you would like one anyway.

The following is the output from Valgrind:

==13689== Memcheck, a memory error detector.
==13689== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==13689== Using LibVEX rev 1854, a library for dynamic binary translation.
==13689== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==13689== Using valgrind-3.3.1, a dynamic binary instrumentation framework.
==13689== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==13689== For more details, rerun with: -v
==13689==
FFmpeg version SVN-r14338, Copyright (c) 2000-2008 Fabrice Bellard, et al.
  configuration: --enable-debug=3
  libavutil version: 49.7.0
  libavcodec version: 51.60.0
  libavformat version: 52.17.0
  libavdevice version: 52.0.0
  built on Jul 22 2008 13:17:22, gcc: 4.1.2 20061115 (prerelease) (Debian 
4.1.1-21)
==13689== Invalid read of size 4
==13689== Stack hash: 137218917
==13689==    at 0x82DCB65: mp_decode_frame (bitstream.h:619)
==13689==  Address 0x43c4f66 is 422 bytes inside a block of size 425 alloc'd
==13689== Stack hash: 2626001482
==13689==    at 0x401C882: memalign (vg_replace_malloc.c:460)
==13689==    by 0x8439F80: av_malloc (mem.c:61)
==13689==
==13689== Invalid read of size 4
==13689== Stack hash: 137219122
==13689==    at 0x82DCC32: mp_decode_frame (bitstream.h:619)
==13689==  Address 0x43c4f67 is 423 bytes inside a block of size 425 alloc'd
==13689== Stack hash: 2626001482
==13689==    at 0x401C882: memalign (vg_replace_malloc.c:460)
==13689==    by 0x8439F80: av_malloc (mem.c:61)
==13689==
==13689== Invalid read of size 4
==13689== Stack hash: 137219259
==13689==    at 0x82DCCBB: mp_decode_frame (bitstream.h:619)
==13689==  Address 0x43c4f69 is 0 bytes after a block of size 425 alloc'd
==13689== Stack hash: 2626001482
==13689==    at 0x401C882: memalign (vg_replace_malloc.c:460)
==13689==    by 0x8439F80: av_malloc (mem.c:61)
==13689==
==13689== Invalid read of size 4
==13689== Stack hash: 137220085
==13689==    at 0x82DCFF5: mp_decode_frame (bitstream.h:619)
==13689==  Address 0x43c4f6c is 3 bytes after a block of size 425 alloc'd
==13689== Stack hash: 2626001482
==13689==    at 0x401C882: memalign (vg_replace_malloc.c:460)
==13689==    by 0x8439F80: av_malloc (mem.c:61)
Input #0, mp3, from '../Desktop/1659-m_cut.3.mp4':
  Duration: 00:00:20.22, start: 0.000000, bitrate: 128 kb/s
    Stream #0.0: Audio: mp3, 11025 Hz, mono, 128 kb/s
Output #0, mp2, to '../Desktop/1659-m_cut.3.mp3':
    Stream #0.0: Audio: mp2, 11025 Hz, mono, 64 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
[mp2 @ 0x445de90]Sampling rate 11025 is not allowed in mp2
Error while opening codec for output stream #0.0 - maybe incorrect parameters
such as bit_rate, rate, width or height
==13689==
==13689== ERROR SUMMARY: 128 errors from 4 contexts (suppressed: 17 from 1)
==13689== malloc/free: in use at exit: 291,603 bytes in 39 blocks.
==13689== malloc/free: 412 allocs, 373 frees, 3,173,275 bytes allocated.
==13689== For counts of detected errors, rerun with: -v
==13689== searching for pointers to 39 not-freed blocks.
==13689== checked 2,558,316 bytes.
==13689==
==13689== LEAK SUMMARY:
==13689==    definitely lost: 20 bytes in 2 blocks.
==13689==      possibly lost: 0 bytes in 0 blocks.
==13689==    still reachable: 291,583 bytes in 37 blocks.
==13689==         suppressed: 0 bytes in 0 blocks.
==13689== Rerun with --leak-check=full to see details of leaked memory.


This bug was found using the Zzuf fuzzer. It was found as part of the
SUPERB-TRUST 2008 project ( see http://www.truststc.org/superb/ ) and the
metafuzz project ( see http://metafuzz.com ).

Let me know if I can provide more information.

______________________________________________________
FFmpeg issue tracker <[EMAIL PROTECTED]>
<https://roundup.mplayerhq.hu/roundup/ffmpeg/issue552>
______________________________________________________

Reply via email to