First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 100869
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: media-video herd <media-video@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Klaus Stengel <proger2@technologist.com>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
libquicktime094.patch replacement patch file patch Klaus Stengel 2005-07-31 02:42 0000 12.81 KB Details | Diff
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 100869 depends on: Show dependency tree
Bug 100869 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2005-07-31 02:21 0000
The lavtools leak memory when writing avi files. After a few minutes they
usually take some hundred Megabytes of RAM and eventually, when all available
memory is occupied, they get killed by the kernel. Because of this it is no
longer possible to record/process anything bigger than 10-20 minutes.

Trying to record/save in quicktime .mov format helped me to circumvent the
memory leak but broke the audio track instead; Trying to use any other sound
format than 16 bit stereo obviously doesn't work. Depending on the selected
bits/channel combination you could get anything from garbled sound to almost
immediate crashes (i.e. segmentation fault or some memory corruption in glib).

The problems described here only occur with the quicktime USE-flag set. The
whole lavtools got almost unusable in this configuration with mjpegtools-1.6.2-r4.

Reproducible: Always
Steps to Reproduce:
AVI Memory leak:
Try to record an avi file by running "lavrec -s test.avi"
As an alternative you can try to convert some large quicktime move with
lavtrans, i.e. "lavtrans -o test.avi test.mov"

Quicktime crash/sound problem:
1. Try to record an quicktime file by running "lavrec -s -a 8 test.mov",
"lavrec -a 8 test.mov", or simply "lavrec test.mov".
2. If you were lucky and lavrec didn't crash, try to play the resulting file
with some media player. As an alternative you can try to convert some random avi
file with 8bit/mono, 8bit/stereo or 16bit/mono soundtrack to quicktime with
lavtrans.

Actual Results:  
AVI Memory leak:
Memory and Swap gets filled and then the program is killed.

Quicktime crash/sound problem:
lavrec/lavtrans crashes with a segmentation fault or a message that some memory
corruption happened somewere in glib. If the program didn't crash and you play
the resulting file, the sound is garbled (a few octaves to high and very noisy).

Expected Results:  
The programs should not use excessive amounts of memory when writing AVI files
and should not crash or corrupt the audio track in quicktime movies.


Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.5-20050130,
glibc-2.3.5-r0, 2.6.12-gentoo-r6 i686)
=================================================================
System uname: 2.6.12-gentoo-r6 i686 AMD Athlon(tm) XP 1700+
Gentoo Base System version 1.6.13
dev-lang/python:     2.3.5
sys-apps/sandbox:    1.2.11
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5
sys-devel/binutils:  2.15.92.0.2-r10
sys-devel/libtool:   1.5.18-r1
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -O2 -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon-xp -O2 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo
http://ftp.uni-erlangen.de/pub/mirrors/gentoo
ftp://ftp.tu-clausthal.de/pub/linux/gentoo"
LANG="de_DE@euro"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/mnt/bkdisk/buildtmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 3dnow X X509 acpi alsa avi berkdb bitmap-fonts cdr crypt cscope cups
curl dga dv dvd eds emboss encode esd faad fam flac foomaticdb fortran gd gdbm
gif gimpprint gnome gstreamer gtk gtk2 gtkhtml guile hal imagemagick imlib
innodb ipv6 irmc java jpeg kqemu lame ldap libg++ libwww live mad mbox mikmod
mmx mng motif mozilla moznocompose moznoirc moznomail mozsvg mp3 mpeg ncurses
nls nptl ogg oggvorbis opengl oss pam perl pic png python quicktime readline
samba sasl scanner sdl slang softmmu spell sse ssl svg tcpd tiff truetype
truetype-fonts type1-fonts vim-with-x vorbis wmf wxgtk1 x11vnc xml2 xscreensaver
xv xvid zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LC_ALL, LDFLAGS, LINGUAS

------- Comment #1 From Klaus Stengel 2005-07-31 02:42:54 0000 -------
Created an attachment (id=64775) [details]
replacement patch file

I found out that the problems mentioned above are caused by the patch located
in
media-video/mjpegtools/files/mjpegtools-1.6.2-libquicktime094.patch
in the portage tree. It is broken in several ways, i.e. allocating/freeing
memory in the wrong places among ignoring different sample formats, among some
other things.

I finally fixed those bugs and created a replacement for that broken patch.

------- Comment #2 From Diego E. 'Flameeyes' Pettenò 2005-12-17 17:55:11 0000 -------
Calling arches. mjpegtools-1.8.0 is safe (as it does not use the patch), that
should probably be marked stable to fix this bug, as changing the patch would
anyway require a revbump losing stable.

------- Comment #3 From Markus Rothe 2005-12-18 01:38:58 0000 -------
you mean mjpegtools-1.8.0-r1, don't you?

------- Comment #4 From Diego E. 'Flameeyes' Pettenò 2005-12-18 06:07:36 0000 -------
Yep sorry, making more informative the subject, too

------- Comment #5 From Markus Rothe 2005-12-19 02:34:12 0000 -------
stable on ppc64

------- Comment #6 From Gustavo Zacarias (RETIRED) 2005-12-20 10:25:06 0000 -------
sparc stable.

------- Comment #7 From Mark Loeser 2005-12-20 20:37:48 0000 -------
x86 done

------- Comment #8 From Simon Stelling (RETIRED) 2005-12-26 01:42:01 0000 -------
amd64 stable
also removing ppc since hansmi already marked it stable

------- Comment #9 From Diego E. 'Flameeyes' Pettenò 2006-02-04 08:42:14 0000 -------
Alpha? You're the last needing to stable this to be able to drop the
non-modular version.

------- Comment #10 From Fernando J. Pereda (RETIRED) 2006-02-08 04:40:06 0000 -------
Alpha done by agriffis. Resolving since we are last on the list.

First Last Prev Next    No search results available      Search page      Enter new bug