Vladimir Eremeev <[EMAIL PROTECTED]> added the comment:

> 1. The bug has in no way been analyzed you are randomly 
> guessing at best if even that. 
I am not familiar with your terminology. I would call my 
actions the analyzis and therefore the bug status analyzed, 
and your assumptions about my methods are wrong.

> 2. You have been asked to provide valgrind output you did 
not.
> 3. You do not use the latest revision of ffmpeg []
> 4. you link with Wl,--allow-multiple-definition []

These points are wrong. Issue tracker has crashed yesterday 
when I was submitting the message in fulfillment of these, 
therefore I have uploaded files to upload.mplayer.hu and 
written a message to ffmpeg-devel.

> 5. There where 2 small leaks in the mpeg ts demuxer which 
have been fixed

Thank you, Mpeg TS part seems to be not leaking anymore.
The leak in the AC3 parser is still persists.
Yesterday, I was unable to locate my uploaded files. Please, 
notify me if I have to submit them again.

Below is the valgrind output for the leak with FFmpeg 
revision 12946 (and other details).

FFmpeg Revision: 12946

FFmpeg configure switches:

# for usual operation:
#./configure --enable-shared --disable-static --disable-
stripping --cpu=i686 --enable-debug=3 --enable-pthreads

# for valgrind
./configure --disable-optimizations --disable-mmx --disable-
ssse3 --disable-mmx2 --enable-shared --disable-static --
disable-stripping --cpu=i686 --enable-debug=3 --enable-
pthreads --extra-cflags="-O0 -fno-inline"

$ ffmpeg -version
FFmpeg version SVN-r12947, Copyright (c) 2000-2008 Fabrice 
Bellard, et al.
  configuration: --disable-optimizations --disable-mmx --
disable-ssse3 --disable-mmx2 --enable-shared --disable-static 
--disable-stripping --cpu=i686 --enable-debug=3 --enable-
pthreads --extra-cflags=-O0 -fno-inline
  libavutil version: 49.6.0
  libavcodec version: 51.56.0
  libavformat version: 52.13.0
  libavdevice version: 52.0.0
  built on Apr 25 2008 12:16:35, gcc: 3.4.3 20050227 (Red Hat 
3.4.3-22.1)
FFmpeg SVN-r12947
libavutil   3212800
libavcodec  3356672
libavformat 3411200
libavdevice 3407872


Test program compilation command
$ gcc -o mf_read mf_read.c -O0 -g3 -lavcodec -lavformat -
lavutil -lm -lpthread -lz

File issue430_wl2776_dump.ts was uploaded yesterday (24 Apr 
2008) to ftp://upload.mplayer.hu

===============

Valgrind call and output:

$ valgrind --leak-check=full --show-reachable=yes --leak-
resolution=high ./mf_read
==11641== Memcheck, a memory error detector.
==11641== Copyright (C) 2002-2007, and GNU GPL'd, by Julian 
Seward et al.
==11641== Using LibVEX rev 1804, a library for dynamic binary 
translation.
==11641== Copyright (C) 2004-2007, and GNU GPL'd, by 
OpenWorks LLP.
==11641== Using valgrind-3.3.0, a dynamic binary 
instrumentation framework.
==11641== Copyright (C) 2000-2007, and GNU GPL'd, by Julian 
Seward et al.
==11641== For more details, rerun with: -v
==11641==
input format: mpegts (0x45744a0)
av_open_input_stream (issue430_wl2776_dump.ts), ret=0
av_find_stream_info, ret=3311
packets read: 4000
finished
==11641==
==11641== ERROR SUMMARY: 0 errors from 0 contexts 
(suppressed: 22 from 1)
==11641== malloc/free: in use at exit: 209,648 bytes in 4 
blocks.
==11641== malloc/free: 77,405 allocs, 77,401 frees, 
49,152,885 bytes allocated.
==11641== For counts of detected errors, rerun with: -v
==11641== searching for pointers to 4 not-freed blocks.
==11641== checked 1,168,952 bytes.
==11641==
==11641== 94,252 bytes in 2 blocks are definitely lost in 
loss record 1 of 2
==11641==    at 0x4005E39: realloc (vg_replace_malloc.c:429)
==11641==    by 0x457BE7A: av_realloc (mem.c:110)
==11641==    by 0x407D8F4: av_fast_realloc (utils.c:69)
==11641==    by 0x407AC77: ff_combine_frame (parser.c:252)
==11641==    by 0x4333941: ff_aac_ac3_parse 
(aac_ac3_parser.c:62)
==11641==    by 0x407A8FB: av_parser_parse (parser.c:136)
==11641==    by 0x44E7F17: av_read_frame_internal 
(utils.c:798)
==11641==    by 0x44EB11D: av_find_stream_info (utils.c:1897)
==11641==    by 0x8048969: main (mf_read.c:68)
==11641==
==11641==
==11641== 115,396 bytes in 2 blocks are definitely lost in 
loss record 2 of 2
==11641==    at 0x4005E39: realloc (vg_replace_malloc.c:429)
==11641==    by 0x457BE7A: av_realloc (mem.c:110)
==11641==    by 0x407D8F4: av_fast_realloc (utils.c:69)
==11641==    by 0x407AC77: ff_combine_frame (parser.c:252)
==11641==    by 0x4333941: ff_aac_ac3_parse 
(aac_ac3_parser.c:62)
==11641==    by 0x407A8FB: av_parser_parse (parser.c:136)
==11641==    by 0x44E7F17: av_read_frame_internal 
(utils.c:798)
==11641==    by 0x44E8626: av_read_frame (utils.c:953)
==11641==    by 0x80489D5: main (mf_read.c:75)
==11641==
==11641== LEAK SUMMARY:
==11641==    definitely lost: 209,648 bytes in 4 blocks.
==11641==      possibly lost: 0 bytes in 0 blocks.
==11641==    still reachable: 0 bytes in 0 blocks.
==11641==         suppressed: 0 bytes in 0 blocks.

----------
priority: normal -> important
status: closed -> open
substatus: fixed -> open

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

Reply via email to