Portage 2.1_pre4-r1 (default-linux/x86/2005.0, gcc-3.4.5, glibc-2.3.6-r2, 2.6.10-gentoo-r6 i686) ================================================================= System uname: 2.6.10-gentoo-r6 i686 Intel(R) Pentium(R) M processor 2.00GHz Gentoo Base System version 1.12.0_pre15 ccache version 2.4 [enabled] dev-lang/python: 2.3.4-r1, 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium-m -pipe -fomit-frame-pointer -msse -msse2 -mmmx" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O3 -march=pentium-m -pipe -fomit-frame-pointer -msse -msse2 -mmmx" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://distro.ibiblio.org/pub/linux/distributions/gentoo/ http://gentoo.chem.wisc.edu/gentoo/ http://prometheus.cs.wmich.edu/gentoo http://mirror.mcs.anl.gov/pub/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="x86 X acpi alsa apm avi berkdb bitmap-fonts browserplugin cdr crypt cups directfb divx4linux doc dv dvd eds emboss encode esd fbcon foomaticdb fortran gdbm gif gnustep gpm gstreamer gtk gtk2 imlib ipv6 ithreads jce jpeg libg++ libwww mad mbox mikmod mmx motif mozcalendar mozdevelop mozsvg mp3 mpeg mppe-mppc ncurses nls nptl nptlonly nsplugin objc ogg oggvorbis opengl oss pam pda pdflib perl png pnp python qt quicktime readline rtc sdk sdl spell sse sse2 ssl tcpd tetex threads truetype truetype-fonts type1-fonts vorbis win32codecs xml xml2 xmms xv zlib elibc_glibc kernel_linux userland_GNU video_cards_nvidia" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Submitted that last one a little quick... (oops) When I attempt to play a dv file with 104-r1, it segfaults: $ playdv some_file.dv format 4:3 Audio is 44.1 kHz, 16 bits quantization, 2 channels, emphasis off Xv: NV17 Video Overlay: ports 260 - 260 Xv: grabbed port 260 Using Xv for display Segmentation fault if I use SDL or Gtk, I get the similar errors. Previous ebuilds (104 and 102 work fine). Just this r1 release is seg faulting.
The problem is introduced in the PIC patch. I ran gdb and gstreamer and came with these backtraces: (gdb) bt #0 0xb7adab2c in dv_parse_ac_coeffs_pass0@plt () from /usr/lib/libdv.so.4 #1 0xb7aeb73d in dv_parse_video_segment () from /usr/lib/libdv.so.4 #2 0x0000000c in ?? () #3 0xb7679044 in ?? () #4 0xb7af0598 in ?? () from /usr/lib/libdv.so.4 #5 0xb7adb84d in dv_decode_full_frame () from /usr/lib/libdv.so.4 #6 0x00000005 in ?? () #7 0x00000190 in ?? () #8 0x00000000 in ?? () Compiled with -O2 -march=pentium4 -g 0xb7a61b2c in dv_parse_ac_coeffs_pass0@plt () from /usr/lib/libdv.so.4 (gdb) bt #0 0xb7a61b2c in dv_parse_ac_coeffs_pass0@plt () from /usr/lib/libdv.so.4 #1 0xb7a731b5 in dv_parse_video_segment () from /usr/lib/libdv.so.4 #2 0x00000000 in ?? () Without the pic patch it plays, if it 'works' I can't say yet :)
Cinelerra is experiencing problems with libdv, too. With Cinelerra, libdv-0.102 works for a little while, and 0.104-r1 for much worse. libdv from CVS seems rock-solid (compared to the others, anyway). For more info, see http://bugs.cinelerra.org/show_bug.cgi?id=248
my best luck so far has just been using 0.104... (no r1). Thus my /etc/portage/package.mask contains: >media-libs/libdv-0.104 Having masked r1, I've had no problems using the library directly, kino, or cinelerra (although I rarely user cinelerra so your milage may vary) so unless there is a reason not to, I'd say to mask r1 in the portage tree...
I can confirm this bug on one of my boxes.
I can confirm this bug on my x86 boxes. It happens when decoding any dv file with libdv. It is due to the pic patch. Same ebuild without pic patch makes it not crash.
Created attachment 87419 [details, diff] fixed PIC patch i don't know what happened here, i'd fixed this on new year's eve (don't ask :P) and sent it to a few people. anyway, please give it a try and let us know if it fixes the crashes. iirc, GNU_STACK still needs a patch, but it's low priority for me.
heh ive got a bunch of libdv local work myself i never got around to finishing up
This new patch also makes playdv segfault on x86.
(In reply to comment #9) > This new patch also makes playdv segfault on x86. could you do a little debugging (generate coredump, analyze it in gdb) or at least tell us how to reproduce the crash?
Created attachment 88334 [details, diff] cleaned up PIC fix this new patch removes an extra file added by mistake and also consolidates the libdv-0.104-gcc4.patch fix as the problem was introduced by me, so it's better to get it right here. and of course if anyone sees any crashes, report them here, preferably with some info you get from gdb (at least a backtrace, stack/register dump, disassembly).
(In reply to comment #11) > Created an attachment (id=88334) [edit] > cleaned up PIC fix > > this new patch removes an extra file added by mistake and also consolidates the > libdv-0.104-gcc4.patch fix as the problem was introduced by me, so it's better > to get it right here. and of course if anyone sees any crashes, report them > here, preferably with some info you get from gdb (at least a backtrace, > stack/register dump, disassembly). This new patch doesn't fix the issue for me. A gdb backtrace gives the exact same output as for Stefan de Konink above. If I coment the PIC fix and associated gcc4 patche in the ebuild, I get the TEXTREL warning but everything works again. Denis. Denis.
unfortunately the stack trace is not enough, i need the register dump and some disassembly as well. try these gdb commands please: x/16i $pc info reg
Created attachment 89150 [details, diff] next attempt ;) i think i found the bug plus simplified some other code, give it a try.
Still the same thing with your latest attempt. Here's the gdb output : Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1222441296 (LWP 29165)] 0xb7f0b859 in dv_parse_ac_coeffs_pass0 () from /usr/lib/libdv.so.4 (gdb) x/16i $pc 0xb7f0b859 <dv_parse_ac_coeffs_pass0+321>: movzbl (%ebx),%eax 0xb7f0b85c <dv_parse_ac_coeffs_pass0+324>: inc %ebx 0xb7f0b85d <dv_parse_ac_coeffs_pass0+325>: shr $0x10,%edx 0xb7f0b860 <dv_parse_ac_coeffs_pass0+328>: mov %dx,0x0(%ebp,%eax,1) 0xb7f0b865 <dv_parse_ac_coeffs_pass0+333>: jmp 0xb7f0b785 <dv_parse_ac_coeffs_pass0+109> 0xb7f0b86a <dv_parse_ac_coeffs_pass0+338>: mov 0x88(%ebp),%ebx 0xb7f0b870 <dv_parse_ac_coeffs_pass0+344>: test $0xffff0000,%edx 0xb7f0b876 <dv_parse_ac_coeffs_pass0+350>: jne 0xb7f0b897 <dv_parse_ac_coeffs_pass0+383> 0xb7f0b878 <dv_parse_ac_coeffs_pass0+352>: mov 0x8c(%ebp),%ebx 0xb7f0b87e <dv_parse_ac_coeffs_pass0+358>: add $0x4,%edi 0xb7f0b881 <dv_parse_ac_coeffs_pass0+361>: movl $0x1,0x98(%ebp) 0xb7f0b88b <dv_parse_ac_coeffs_pass0+371>: mov 0x18(%esp),%edx 0xb7f0b88f <dv_parse_ac_coeffs_pass0+375>: incl 0x3e4(%edx) 0xb7f0b895 <dv_parse_ac_coeffs_pass0+381>: jmp 0xb7f0b8b3 <dv_parse_ac_coeffs_pass0+411> 0xb7f0b897 <dv_parse_ac_coeffs_pass0+383>: and $0xff00,%edx 0xb7f0b89d <dv_parse_ac_coeffs_pass0+389>: cmp $0xfe00,%edx (gdb) info reg eax 0x1 1 ecx 0x3d 61 edx 0xffff0501 -64255 ebx 0x12040211 302252561 esp 0xbfd457fc 0xbfd457fc ebp 0xbfd458e8 0xbfd458e8 esi 0xb7f1016c -1208942228 edi 0x31 49 eip 0xb7f0b859 0xb7f0b859 <dv_parse_ac_coeffs_pass0+321> eflags 0x210206 2163206 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 And here's my emerge info : Portage 2.1 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.16-gentoo-r8 i686) ================================================================= System uname: 2.6.16-gentoo-r8 i686 AMD Athlon(tm) XP 1600+ Gentoo Base System version 1.12.1 dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r2 sys-devel/gcc-config: [Not Present] sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -pipe -O2 -fomit-frame-pointer -fno-ident -fforce-addr -ftracer -fweb -ffast-math" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=athlon-xp -pipe -O2 -fomit-frame-pointer -fno-ident -fforce-addr -ftracer -fweb -ffast-math -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X a52 aac acpi alsa apache2 avi bash-completion berkdb bitmap-fonts bzip2 cairo cdparanoia cdr cjk cli crypt dbus djbfft dri dv dvd dvdr dvdread editor edl emboss encode exif ffmpeg firefox flac foomaticdb fortran gcj gd gdbm gif glibc-omitfp glitz gmail gnome gphoto2 gtk gtk2 hal hou howl ieee1394 ilbc imlib ipv6 isdnlog java jpeg lcms libg++ libwww live logrotate lzo mad matroska mikmod mmx mmxext mng motif moznocompose moznoirc moznomail mozsvg mp3 mpeg mpi music nautilus ncurses network nls nowin nptl nptlonly nsplugin nvidia ogg opengl oss pam pcre pdflib perl pic plotutils png pppd python quicktime readline real reflection rle rtc sdl session silc sndfile sou sox speex spell spl sse ssl svg tcltk tcpd theora tiff truetype truetype-fonts type1-fonts udev unicode userlocales vorbis vorbis-psy win32codecs wmf xanim xchattext xml xorg xv xvid xvmc zlib elibc_glibc input_devices_mouse input_devices_keyboard kernel_linux userland_GNU video_cards_nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS Note that I'm also using my --as-needed patch (see bug #136028), bus as it is only commenting 2 lines in the configure script, it should have no impact (it prevents clearing GTK_CFLAGS and GTK_LIBS when the gtk test fails due to -as-needed). Denis.
Created attachment 89212 [details, diff] final one ;P i think i fixed it for good this time.
(In reply to comment #16) > Created an attachment (id=89212) [edit] > final one ;P > > i think i fixed it for good this time. Sorry, but I'm still having the same issue. Here's the gdb output: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1222228304 (LWP 31588)] 0xb7f3f859 in dv_parse_ac_coeffs_pass0 () from /usr/lib/libdv.so.4 (gdb) x/16i $pc 0xb7f3f859 <dv_parse_ac_coeffs_pass0+321>: movzbl (%ebx),%eax 0xb7f3f85c <dv_parse_ac_coeffs_pass0+324>: inc %ebx 0xb7f3f85d <dv_parse_ac_coeffs_pass0+325>: shr $0x10,%edx 0xb7f3f860 <dv_parse_ac_coeffs_pass0+328>: mov %dx,0x0(%ebp,%eax,1) 0xb7f3f865 <dv_parse_ac_coeffs_pass0+333>: jmp 0xb7f3f785 <dv_parse_ac_coeffs_pass0+109> 0xb7f3f86a <dv_parse_ac_coeffs_pass0+338>: mov 0x88(%ebp),%ebx 0xb7f3f870 <dv_parse_ac_coeffs_pass0+344>: test $0xffff0000,%edx 0xb7f3f876 <dv_parse_ac_coeffs_pass0+350>: jne 0xb7f3f897 <dv_parse_ac_coeffs_pass0+383> 0xb7f3f878 <dv_parse_ac_coeffs_pass0+352>: mov 0x8c(%ebp),%ebx 0xb7f3f87e <dv_parse_ac_coeffs_pass0+358>: add $0x4,%edi 0xb7f3f881 <dv_parse_ac_coeffs_pass0+361>: movl $0x1,0x98(%ebp) 0xb7f3f88b <dv_parse_ac_coeffs_pass0+371>: mov 0x18(%esp),%edx 0xb7f3f88f <dv_parse_ac_coeffs_pass0+375>: incl 0x3e4(%edx) 0xb7f3f895 <dv_parse_ac_coeffs_pass0+381>: jmp 0xb7f3f8b3 <dv_parse_ac_coeffs_pass0+411> 0xb7f3f897 <dv_parse_ac_coeffs_pass0+383>: and $0xff00,%edx 0xb7f3f89d <dv_parse_ac_coeffs_pass0+389>: cmp $0xfe00,%edx (gdb) info reg eax 0x1 1 ecx 0x3d 61 edx 0xffff0501 -64255 ebx 0x12040211 302252561 esp 0xbff79e9c 0xbff79e9c ebp 0xbff79f88 0xbff79f88 esi 0xb7f4416c -1208729236 edi 0x31 49 eip 0xb7f3f859 0xb7f3f859 <dv_parse_ac_coeffs_pass0+321> eflags 0x210206 2163206 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 Anything else I can do to help you ? Denis.
Created attachment 89932 [details, diff] real final one ;) i managed to reproduce and debug the crash, this one works here on a test .dv file. however i ran across another bug, glibc's double free check triggers when playdv exits. also, USE=sdl produces something that crashes on its own due to dereferencing a lot of X related pointers that are NULL (some failure to initialize them, but i don't where that comes from).
Yup, final patch fixes the problem here using gcc-3.4.6 on x86 (unable to test gcc-4.x.x) My problem was that media-video/mjpegtools (compiled against media-libs/libdv) was also segfaulting on "dv_parse_ac_coeffs_pass.." from /usr/lib/libdv.so.4 Previous to this patch I was disabling the libdv-0.104-gcc4.patch to workaround (PIC patch had no adverse affect). Disabling all patches & enabling this latest patch fixes. "also, USE=sdl produces something that crashes on its own ..." Would that be when using anything >=libsdl-1.2.10 ? This version is known to affect/break many apps. at the moment.
(In reply to comment #19) > "also, USE=sdl produces something that crashes on its own ..." > > Would that be when using anything >=libsdl-1.2.10 ? > This version is known to affect/break many apps. at the moment. yes, that's what i have here, but can't tell if previous versions had this issue as well or not.
Great! It now works without crashing....however, the picture looks very ruff compared to what it looks like without the patch completely (at least on my box). I'm running ~arch on a pentium m.
Created attachment 90100 [details, diff] absolutely final one a.k.a. how not to look like an idiot ;-) silly oversight, this one works on pond.dv, there're no artifacts anymore. btw, while looking for a good test case i ran across the libdv dev list at sourceforge and apparently fedora core 5 has included the earlier and buggy version. also, based on a mail there this might be submitted upstream.
Works great for me...thanks for all the work.
I just umasked r1 and it still segfaults for me (system info above [initial report]), remasking and rolling back works fine still.
actually, some things have changed... here: Portage 2.1.1_pre1-r5 (default-linux/x86/2006.0, gcc-3.4.6/vanilla, glibc-2.4-r3, 2.6.11-gentoo-r9 i686) ================================================================= System uname: 2.6.11-gentoo-r9 i686 Intel(R) Pentium(R) M processor 2.00GHz Gentoo Base System version 1.12.1 ccache version 2.4 [enabled] dev-lang/python: 2.3.4-r1, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r2 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17 sys-devel/gcc-config: 2.0.0_rc1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium-m -pipe -fomit-frame-pointer -msse -msse2 -mmmx" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O3 -march=pentium-m -pipe -fomit-frame-pointer -msse -msse2 -mmmx" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://distro.ibiblio.org/pub/linux/distributions/gentoo/ http://gentoo.chem.wisc.edu/gentoo/ http://prometheus.cs.wmich.edu/gentoo http://mirror.mcs.anl.gov/pub/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="x86 X aac acpi alsa apache2 apm asf avi berkdb bitmap-fonts browserplugin cdr cli crypt cups directfb divx4linux doc dri dv dvd eds emboss encode esd fbcon foomaticdb fortran gdbm gif gnustep gpm gstreamer gtk gtk2 imlib ipv6 isdnlog ithreads jce joystick jpeg libg++ libwww mad mbox mikmod mmx motif mozcalendar mozdevelop mozsvg mp3 mpeg mppe-mppc ncurses nls nptl nptlonly nsplugin nvidia objc ogg opengl oss pam pcre pda pdflib perl png pnp ppds pppd python qt qt3 qt4 quicktime readline reflection rtc sdk sdl session spell spl sse sse2 ssl tcpd tetex threads truetype truetype-fonts type1-fonts udev vorbis win32codecs xml xmms xorg xv xvid zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_joystick kernel_linux userland_GNU video_cards_nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
(In reply to comment #24) > I just umasked r1 and it still segfaults for me (system info above [initial > report]), remasking and rolling back works fine still. portage doesn't have the fix yet, you have to manually apply it.
oops. =) yup, it works.
Hi, issue resolved also for me! I have a Pentium IV, emerged cinelerra-cvs with: media-video/cinelerra-cvs -hardened (maybe it's not necessary), and gcc version i686-pc-linux-gnu-3.3.5-20050130-vanilla ; emerge --info is: Portage 2.1-r1 (default-linux/x86/2006.0, gcc-vanilla, glibc-2.3.6-r4, 2.6.17-gentoo i686) ================================================================= System uname: 2.6.17-gentoo i686 Intel(R) Pentium(R) 4 CPU 3.20GHz Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5, 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium4 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /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/" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/splash /etc/terminfo" CXXFLAGS="-O3 -march=pentium4 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.gentoo.mesh-solutions.com/gentoo/" LANG="en_GB" LC_ALL="en_GB" LINGUAS="en it " MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/home/DATI/computer/ooptgtoo/vartmpportage" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aac aalibaccessibility acpi alsa apache2 apm arts avi berkdb bidi bitmap-fonts bluetooth bonobo bzip2 cdparanoia cdr cli crypt cups dbus dga dio directfb dri dv dvb dvd dvdr dvdread eds emacs emboss encode esd examples ffmpeg fftw flash foomaticdb fortran ftp gb gcj gdbm gif ginac gnome gphoto2 gpm gps gstreamer gtk gtk2 guile hal hardened icq idn iee1394 imagemagick imap imlib inifile ipv6 isdnlog jabber jack java javascript joistick jpeg jpeg2k kde kdeenablefinal kdexdeltas libcaca libg++ libwww lirc lm_sensors mad matroska mikmod mime ming mmx mng motif mozilla mp3 mpeg msn mysql mysqli nas ncurses nls nptl offensive ogg openal opengl osc oss pam pcmcia pcre pdf pdflib perl php png pppd prelude python qt qt3 qt4 quicktime readline reflection ruby samba scanner sdl session slang sockets socks5 sox speex spell spl sse sse2 ssl svg tcltk tcpd tiff truetype truetype-fonts type1-fonts udev unicode usb v4l vcd vorbis wifi win32codecs wmf wxwindows xine xinerama xml xml2 xmms xorg xosd xpm xprint xv xvid yahoo zlib elibc_glibc kernel_linux linguas_en linguas_it userland_GNU" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS Ciao and thanks, Leo(In reply to comment #27) > oops. =) > > yup, it works. > (In reply to comment #27) > oops. =) > > yup, it works. >
ive e-mailed all the symbol cleanups upstream, but havent heard back http://sourceforge.net/mailarchive/message.php?msg_id=20652849 i plan on pushing these fixes through one at a time ...
(In reply to comment #29) > ive e-mailed all the symbol cleanups upstream, but havent heard back > http://sourceforge.net/mailarchive/message.php?msg_id=20652849 > > i plan on pushing these fixes through one at a time ... thank you, i hope they'll wake up eventually and respond ;-).
(In reply to comment #22) > Created an attachment (id=90100) [edit] > absolutely final one a.k.a. how not to look like an idiot ;-) > > silly oversight, this one works on pond.dv, there're no artifacts anymore. btw, > while looking for a good test case i ran across the libdv dev list at > sourceforge and apparently fedora core 5 has included the earlier and buggy > version. also, based on a mail there this might be submitted upstream. > Thank for your patch but after I modify my libdv-0.104-r1.ebuild to include it, I can't emerge due to a patch error for the tiny gcc4 fixes. My new src_unpack() funcion is below. Where do I need to apply your patch (saved in libdv-104.patch)? Does it replace libdv-0.104-pic-fix.patch? src_unpack() { unpack ${A} cd "${S}" epatch "${FILESDIR}"/${PN}-0.99-2.6.patch epatch "${FILESDIR}"/${PN}-0.104-amd64reloc.patch epatch "${FILESDIR}"/${PN}-0.104-no-exec-stack.patch # big patch.. test here hard and fast then push upstream #epatch "${WORKDIR}"/libdv-0.104-pic-fix.patch epatch "${FILESDIR}"/libdv-104.patch # tiny gcc4 fixes epatch "${FILESDIR}"/${PN}-0.104-gcc4.patch # fix from fedora epatch "${FILESDIR}"/${PN}-0.103-mmx.patch epatch "${FILESDIR}/${P}-inline.patch" elibtoolize epunt_cxx #74497 } Thanks for all details you can give to make a good ebuild. Regards, David
(In reply to comment #31) > Thank for your patch but after I modify my libdv-0.104-r1.ebuild to include it, > I can't emerge due to a patch error for the tiny gcc4 fixes. did you read comment #11 ? ;-) > My new src_unpack() funcion is below. Where do I need to apply your patch > (saved in libdv-104.patch)? Does it replace libdv-0.104-pic-fix.patch? yes it does.
(In reply to comment #32) > (In reply to comment #31) > > Thank for your patch but after I modify my libdv-0.104-r1.ebuild to include it, > > I can't emerge due to a patch error for the tiny gcc4 fixes. > > did you read comment #11 ? ;-) Yes. All. Doing change without double read of all comment is bad. I promise i'll never do it again. ;-) > > > My new src_unpack() funcion is below. Where do I need to apply your patch > > (saved in libdv-104.patch)? Does it replace libdv-0.104-pic-fix.patch? > > yes it does. > Thank, I can compile a modifier 0.104-r1 version. I'll test playdv at home. Thank a lot.
(In reply to comment #32) > > > My new src_unpack() funcion is below. Where do I need to apply your patch > > (saved in libdv-104.patch)? Does it replace libdv-0.104-pic-fix.patch? > > yes it does. > I'm probably a dummy, but shouldn't that be libdv-0.104-gcc4.patch?
(In reply to comment #34) > (In reply to comment #32) > > > > > My new src_unpack() funcion is below. Where do I need to apply your patch > > > (saved in libdv-104.patch)? Does it replace libdv-0.104-pic-fix.patch? > > > > yes it does. > > > > I'm probably a dummy, but shouldn't that be libdv-0.104-gcc4.patch? > OK. As I said, I'm a dummy. What I guess I should do is: cd files wget http://bugs.gentoo.org/attachment.cgi?id=90100\ mv <attachment> libdv-0.104-pic-fix.patch Then modify the ebuild to use this instead of the one in WORKDIR But I still don't understand what to do about comment 11. Do I just comment out the epatch of the gcc4 patch?
media-video it sounds like we have a winner of a patch here. Mind putting this into ~arch ; Whats is in portage now is faulty and this fixes it.
(In reply to comment #35) > But I still don't understand what to do about comment 11. Do I just comment > out the epatch of the gcc4 patch? correct.
I'm in media-video, but don't usually maintain libdv. However, would there be any objections if I committed this patch and the one in bug #136028 at the same time ? The current ebuild can hardly be more broken that what it is already. Denis.
Has all work on this bug ended?? I still don't see it in portage, even though everybody seems happy about the fix! Please... somebody put this fix in portage, at least in a masked version of libdv, I really need it (The manual apply is not an option for me)
With the patch, these now work nicely for me: dvgrab capture from camera to AVI kino capture from camera and AVI display cinelerra AVI display These do not: playdv dvconnect --send kino send to camera cinelerra send to camera $ playdv test-001.avi Parser error reading first header (Same error for all files, and I can view them with mplayer, cinelerra, kino) $ dvconnect --send --verbose test-001.avi Sent frame xyz (LCD display on camera shakes and occasionally flashes a few colored blocks. Nothing is recorded on tape. dvconnect used to work with this camera a few years ago, though I don't remember which version of libdv and kernel.)
Please test the patch and report back
(In reply to comment #40) > These do not: > playdv > dvconnect --send > kino send to camera > cinelerra send to camera do you mean that if you don't use the textrel patch, all these work fine then?
No, I meant simply that it doesn't work with the textrel patch. At one point, they did work. I haven't used playdv and dvconnect for a long time, I suspect more than two years ago. The package installs quickly enough, so I checked playdv on all available packages. Results not good: media-libs/libdv-0.99-r1 Parser error reading first header media-libs/libdv-0.101 Parser error reading first header media-libs/libdv-0.102 Parser error reading first header media-libs/libdv-0.104 Parser error reading first header media-libs/libdv-0.104-r1 Parser error reading first header 0.104-r1 + textrel Parser error reading first header
My mistake! I was trying to read an AVI file with playdv. Once I converted to DV, both playdv and dvconnect work perfectly! That's with the textrel patch.
Created attachment 95044 [details] Noise in DV file generation OK, this time I think I have a real bug. It's not a crash, but it could be related to this patch. Tell me if I should open a new bug. I tried two ways to convert DV contained in AVI to raw DV, with transcode and with cinelerra. Both use libdv, and both produced output with periodic audio noise, though with somewhat different characteristics. Using transcode-1.0.2-r2 (fresh install), I ran: transcode -i [input.avi] -y dvraw -uyvy -o [output.dv] and out of 6 AVI files, 3 contained introduced noise. Refer to top of attached image: the input (AVI) and output (DV) audio tracks are displayed, and you can see periodic spikes added to the DV tracks. Interval between spikes appears to one frame. The same input file produced the same output file each time (well, I didn't diff them, but they sound the same). Because my files are a several GB each, I tried making a short sample from one of the AVI files that converted to noisy output, but the sample converted OK. As an alternative, I converted with cinelerra. The noise is introduced has a different characteristic, and appears approximately every 62 frames. The one I labeled "nit (2)" repeated about 10 times (at least), gradually changing: the samples at the edges either changed slightly or blended with the original audio signal, but the majority of samples in the middle remained identical (near as I could see). All of which leads me to suspect these are caused by uninitialized data in libdv. Don't know whether this is related to the original patch or not. I'm hoping someone has an idea about what might be causing this, because I'm not familiar with the design of any of this software or with the DV format. However, if the problem is uninitialized data, then I figure valgrind will find it.
(In reply to comment #45) > All of which leads me to suspect these are caused by uninitialized data in > libdv. Don't know whether this is related to the original patch or not. well, at least this one should be easy to answer: recompile libdv without the textrel fix and see if you still get the audio noise (if you're on a hardened kernel with NOELFRELOCS then temporarily disable MPROTECT on transcode or whoever uses the libdv lib). > I'm hoping someone has an idea about what might be causing this, because > I'm not familiar with the design of any of this software or with the DV > format. i'm afraid that's true for most of us here... > However, if the problem is uninitialized data, then I figure valgrind will > find it. this you can do anyway as valgrind could find other memory handling errors as well.
(reply to comment #46) It's not the textrel patch. Noise happens in 0.104, also. valgrind results are good, except for this noise problem which it located right away: uninitialized samples are being encoded as legitimate audio data. It's not clear to me why this is happening. The problem seems to have been present in the library for a long time. I think I need to take this issue to the libdv maintainers.
(In reply to Comment #45 and following) Folks, don't bring completely unrelated issues here. This bug is about segfaults *ONLY*, take you audio noise, --as-needed issues and whatever else to a *NEW* bug. This is not a dumpspace. So: 1/ Is the segfault gone _without_ the textrel patch? 2/ Does the new patch in Comment #22 fix the segfault as well? Anything else -> NEW bug.
(In reply to comment #48) > 1/ Is the segfault gone _without_ the textrel patch? i don't think there ever was a segfault without the patch (at least the one reported in this bug is definitely due to the textrel patch). > 2/ Does the new patch in Comment #22 fix the segfault as well? it only fixes the segfaults (the audio noise stuff came up only recently but it turned out to be an unrelated problem -> new bug), there was no other problem reported against it as far as i know. and yes, based on all the reports since, the latest patch works and i think it's really high time it went into portage.
Disabling all ebuild patches and enabling latest patch contained in Comment #22 fails to compile: make[3]: Entering directory `/var/tmp/portage/libdv-0.104-r1/work/libdv-0.104/libdv' if /bin/sh ../libtool --silent --mode=compile --tag=CC i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -O2 -march=athlon-xp -pipe -fomit-frame-pointer -Wall -MT dv.lo -MD -MP -MF ".deps/dv.Tpo" -c -o dv.lo dv.c; \ then mv -f ".deps/dv.Tpo" ".deps/dv.Plo"; else rm -f ".deps/dv.Tpo"; exit 1; fi dv.c: In function `dv_decode_macroblock': dv.c:224: error: too many arguments to function `_dv_quant_88_inverse_x86' dv.c: In function `dv_decode_video_segment': dv.c:256: error: too many arguments to function `_dv_quant_88_inverse_x86' make[3]: *** [dv.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/libdv-0.104-r1/work/libdv-0.104/libdv' make[2]: *** [all] Error 2 Disabling all ebuild patches and enabling previous patch contained in Comment #18 compiles and works (doesn't segfault), artifacts are still present. There is still a warning produced at compile time on the same section of code: dv.c: In function `dv_decode_macroblock': dv.c:224: warning: passing arg 5 of `_dv_quant_88_inverse_x86' from incompatible pointer type dv.c: In function `dv_decode_video_segment': dv.c:256: warning: passing arg 5 of `_dv_quant_88_inverse_x86' from incompatible pointer type Disabling only the ebuild patch libdv-0.104-pic-fix.patch (which follows that libdv-0.104-gcc4.patch must also be disabled or it won't apply), fixes the segfault and artifacts are gone. Using gcc-3.4.6
(In reply to comment #50) > Disabling all ebuild patches and enabling latest patch contained in Comment #22 > fails to compile: you have to replace the existing PIC fix patch only and keep the rest except for the gcc4 fix which was folded into the new PIC fix.
Replacing the existing PIC fix patch only and keeping the rest except for the gcc4 patch results in the same error: dv.c: In function `dv_decode_macroblock': dv.c:224: error: too many arguments to function `_dv_quant_88_inverse_x86' dv.c: In function `dv_decode_video_segment': dv.c:256: error: too many arguments to function `_dv_quant_88_inverse_x86' Is this perhaps a gcc3 vs. gcc4 thing, where the relevant gcc4 code patching must be in it's own seperate patch and only applied on a gcc version check ?
I don't know if it works or not, but libdv-102, the stable version, doesn't even *compile* on Gentoo 2006.1 (gcc 4.1). I had to use unstable to get a version that compiles (to be able to build other components that depended on it).
(In reply to comment #53) > I don't know if it works or not, but libdv-102, the stable version, doesn't > even *compile* on Gentoo 2006.1 (gcc 4.1). See Comment #48.
(In reply to comment #52) > Replacing the existing PIC fix patch only and keeping the rest except > for the gcc4 patch results in the same error: > > dv.c: In function `dv_decode_macroblock': > dv.c:224: error: too many arguments to function `_dv_quant_88_inverse_x86' > dv.c: In function `dv_decode_video_segment': > dv.c:256: error: too many arguments to function `_dv_quant_88_inverse_x86' can you post the ebuild you're using to produce this? there must be something wrong in there as everyone else seems to have been able to build a working library.
Created attachment 95900 [details] libdv-0.104-r1.ebuild Just checked the ebuild + tried to reproduce and turns out I had a stray patch enabled in the ebuild, which was the reason for it not compiling second time around (Comment #52). My bad, apologies. OK, so have replaced libdv-0.104-pic-fix.patch with that contained in Comment #22 and disabled the libdv-0.104-gcc4.patch and it now compiles (ebuild attached). But the dreaded segfault is back. As mentioned in Comment #19, I am using media-video/mjpegtools to test: lav2yuv dv_clip.avi INFO: [lav2yuv] chroma '422' recommended with this input INFO: [lav2yuv] set default chroma '420jpeg' YUV4MPEG2 W720 H480 F30000:1001 Ib A10:11 C420jpeg Segmentation fault and the fault traced using gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 26156)] 0xb7e2b6e4 in dv_parse_ac_coeffs_pass0@plt () from /usr/lib/libdv.so.4 Again, disabling the PIC patch and the gcc4 patch solves this, thanks.
(In reply to comment #56) > OK, so have replaced libdv-0.104-pic-fix.patch with that contained in Comment > #22 and disabled the libdv-0.104-gcc4.patch and it now compiles (ebuild > attached). your ebuild takes the PIC patch from WORKDIR, are you sure it is the new one and not the old one portage downloaded as specified in SRC_URI? > lav2yuv dv_clip.avi can you provide a small .avi to reproduce this? looks like i'm short on motion jpeg files ;-). > and the fault traced using gdb: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 16384 (LWP 26156)] > 0xb7e2b6e4 in dv_parse_ac_coeffs_pass0@plt () from /usr/lib/libdv.so.4 i'll need these too: bt x/8x $sp x/8i $pc info regs
*sigh* - you were spot on. It was using the old patch contained in WORKDIR instead of the new one I'd thrown in FILESDIR. Apologies again :( The patch works, gone are the segfault and artifacts, many thanks. Seems there is no need for me now to provide a sample, the file was simply created with: 'ffmpeg -i some_file.mpg -vcodec dvvideo test.avi'
arch team mind if I commit the fix?
amd64 doesn't, go on
13:25:01 <@lu_zero> jakub I hadn't committed libdv since looks broke with the patch 13:25:04 <@leio> as-needed wants fixing in paludis, too ;) 13:25:18 <@jakub> lu_zero: ok, can we nuke the damned patch altogether? 13:25:33 <@jakub> better none patch than a broken one that makes it segfault 13:26:39 <@lu_zero> jakub prod hardened people /me prods hardened people - the broken patch needs to go. It breaks the thing and current stable won't compile w/ gcc-4, people are filing tons of duplicates about this and we can't stabilize a segfaulting thing.
I'm away from CVS/SVN and will be for a few more weeks.. I'd drop the patch in favor of this patch.. Surely somebody can commit that..
(In reply to comment #62) > I'm away from CVS/SVN and will be for a few more weeks.. I'd drop the patch in > favor of this patch.. Surely somebody can commit that.. Maybe you've missed it above, lu_zero says the new patch is broken as well.
I dont see that.. I see him asking if any arch teams see a problem with him commiting the fixed version.
(In reply to comment #64) > I dont see that.. I see him asking if any arch teams see a problem with him > commiting the fixed version. Comment #61 ;)
Commant #61 does not count. He has not stated that on this bug. So whatever was stated on IRC might be speaking of a patch before the final one here.
(In reply to comment #66) > Commant #61 does not count. He has not stated that on this bug. So whatever was > stated on IRC might be speaking of a patch before the final one here. No, he's speaking about this one patch I've been nagging all available media-video folks about for some two weeks by now (since gcc-4.1 went stable). And it's a paste from about one hour ago. There's nothing to commit for the old broken patch, it's sadly been already commited and broke Fedora as well meanwhile (and has been dropped there).
Ok.. We can't even hope to see a fixed patch with vague comments such as "it's broke" that are relayed to bugs via IRC.. Whats broken w/ attachment #90100 [details, diff] ? details please. How to reproduce the SEGV.
i thought this bug was about problems with the textrel fix patch. if there're still outstanding issues, why aren't they reported here? i can't fix stuff i don't even know about...
I can report that the new pic-fix patch is working fine for me. The issues with cinelerra are gone. Therefore it should be included into portage because it can only become better than the current situation.
Created attachment 97939 [details, diff] unify PIC macros and fix/add more symbol cleanups this patch unifies and simplifies the LOAD_PIC_REG() macros when i was sending symbol cleanups upstream i noticed my original stuff had one or two copy & paste errors (ppm vs pgm), so i corrected that and added more of my symbol cleanups here
bah if you are going to do a -r2 stable request at least remove us from the r1 *smacks spanky around* oh crap he'd like that X_X
Created attachment 98094 [details, diff] libdv-1.0.0-pic.patch updated patch for libdv-1.0.0
*** Bug 149196 has been marked as a duplicate of this bug. ***
Does libdv-1.0.0 solves all issues discussed in here? In other words: Is it time to stablize libdv-1.0.0?
no, this bug is not tracking segv issues anymore
I will commit libdv-0.104-r3 and libdv-1.0.0-r1 containing the respective pic-patch, as soon as patches are distributed to mirror://gentoo
Commited to Portage-Tree.
I just installed 1.0.0-r1 flawlessly and will keep an eye on it until it is stabilised. At this momment I can say "works for me"
