On two different systems I ran into trouble getting MythBurnDVD to work properly. It would always segmentation fault when running the "transcode" application. Eventually I tracked the segmentation fault down to a call to jpeg-mmx.so The problem is that the jpeg-mmx library does not function properly when compiled with -fomit-frame-pointer in CFLAGS On two completely different systems (P4 Celeron and a Mobile Athlon XP) the problem was solved by removing that option from CFLAGS. Reproducible: Always Steps to Reproduce: 1.Install MythTV 2.Install MythTVBurn 3.Burn a DVD Actual Results: Segmentation fault running transcode Expected Results: No Segmentation fault. The amount of work required to get a test system set up is probably pretty ridiculous, so I'm not sure if anybody else will be able to back up my findings. But I think that the jpeg-mmx ebuild needs to override the CFLAGS that may be present in make.conf so that the resulting library is robust.
you neglected to post `emerge info` like the bug report page told you to
This is the configuration that causes a faulty jpeg-mmx. I no longer have access to the athlon-xp system, so I can't get info for that one. That system was produced from the latest released Gentoo live-CD, if that is of any interest. To build a jpeg-mmx library that does not crash, I changed the CFLAGS line to CFLAGS="-march=pentium4 -Os" and it no longer crashed. I remember now that the particular application that crashed was jpeg2yuv During the DVD compilation process this application would cause a segfault. By running the application through gdb I was able to determine that it was segfaulting during the call to the jpeg-mmx library. --- Portage 2.0.51.22-r3 (default-linux/x86/2005.0, gcc-3.3.3, glibc-2.3.2-r9, 2.6.9-gentoo-r9 i686) ================================================================= System uname: 2.6.9-gentoo-r9 i686 Intel(R) Celeron(R) CPU 2.00GHz Gentoo Base System version 1.4.16 dev-lang/python: 2.3.3-r1 sys-apps/sandbox: 1.2.10 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.6-r1 sys-devel/binutils: 2.14.90.0.6-r6 sys-devel/libtool: 1.4.3-r4, 1.5.20 virtual/os-headers: 2.4.19 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -Os -pipe -fomit-frame-pointer -mmmx -msse" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -Os -pipe -fomit-frame-pointer -mmmx -msse" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distcc distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aalib alsa apache2 apm audiofile avi berkdb bitmap-fonts bzip2 cdr crypt cups curl dvd eds emboss encode exif expat fam ffmpeg flac foomaticdb fortran gd gdbm ggi gif glut gpm gstreamer gtk2 ieee1394 imagemagick imlib ipv6 java joystick jpeg kde lcms libg++ libwww mad mhash mikmod mmx mmx2 mmxext mng motif mp3 mpeg mysql ncurses nls nvidia ogg oggvorbis opengl oss pam pcre pdflib perl php png python qt quicktime readline samba sdl slang spell sse sse2 ssl svga tcltk tcpd tiff truetype truetype-fonts type1-fonts usb vorbis xine xml2 xmms xv xvid xvmc zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
on x86 hosts, using -march + -Os + other stuff is known to be a bit unstable at times
(In reply to comment #3) > on x86 hosts, using -march + -Os + other stuff is known to be a bit > unstable at times The other machine that experienced the same problem used: CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" I picked that from the following page: http://gentoo-wiki.com/Safe_Cflags Are those flags not indeed "safe"? I just noticed this document: http://www.gentoo.org/proj/en/infrastructure/server-standards.xml#doc_chap1_sect4 In particular: "Note: Sometimes the mmx USE flag can conflict with some of the existing mmx assembly thats used in various multimedia applications that are portage. If you notice this happening try USE="-mmx" and/or appending CFLAGS="-fomit-frame-pointer" In addition seek the help of a developer if needed." I wonder if that's what I'm running into. (Since both systems had MMX USE flags). Either way, couldn't the jpeg-mmx ebuild be modified so that it overrides flags so that it's built in a safe manner?
This is the bug that I previous reported: http://bugs.gentoo.org/show_bug.cgi?id=108810 and others reported having the same issue. It is marked as invalid. It isn't mjpegtools as previous thought, but jpeg-mmx.
confirming. djpeg-mmx segfaults if -fomit-frame-pointer is in CFLAGS. dirtyepic ~ $ cjpeg-mmx -verbose -outfile test1.jpg graphics/ward_whitey.bmp Independent JPEG Group's CJPEG, version 6b 27-Mar-1998 Copyright (C) 1998, Thomas G. Lane 594x619 24-bit BMP image dirtyepic ~ $ djpeg-mmx -verbose -gif -outfile test1.gif test1.jpg Independent JPEG Group's DJPEG, version 6b 27-Mar-1998 Copyright (C) 1998, Thomas G. Lane Start of Image JFIF APP0 marker: version 1.01, density 37x37 2 Define Quantization Table 0 precision 0 Define Quantization Table 1 precision 0 Start Of Frame 0xc0: width=594, height=619, components=3 Component 1: 2hx2v q=0 Component 2: 1hx1v q=1 Component 3: 1hx1v q=1 Define Huffman Table 0x00 Define Huffman Table 0x10 Define Huffman Table 0x01 Define Huffman Table 0x11 Start Of Scan: 3 components Component 1: dc=0 ac=0 Component 2: dc=1 ac=1 Component 3: dc=1 ac=1 Ss=0, Se=63, Ah=0, Al=0 Segmentation fault With frame-pointers: dirtyepic ~ $ djpeg-mmx -verbose -gif -outfile test1.gif test1.jpg Independent JPEG Group's DJPEG, version 6b 27-Mar-1998 Copyright (C) 1998, Thomas G. Lane Start of Image JFIF APP0 marker: version 1.01, density 37x37 2 Define Quantization Table 0 precision 0 Define Quantization Table 1 precision 0 Start Of Frame 0xc0: width=594, height=619, components=3 Component 1: 2hx2v q=0 Component 2: 1hx1v q=1 Component 3: 1hx1v q=1 Define Huffman Table 0x00 Define Huffman Table 0x10 Define Huffman Table 0x01 Define Huffman Table 0x11 Start Of Scan: 3 components Component 1: dc=0 ac=0 Component 2: dc=1 ac=1 Component 3: dc=1 ac=1 Ss=0, Se=63, Ah=0, Al=0 Selected 30 colors for quantization End Of Image Portage 2.1_pre3-r1 (default-linux/x86/2005.1, gcc-4.0.2, glibc-2.3.6-r2, 2.6.15-ck2 i686) ================================================================= System uname: 2.6.15-ck2 i686 Mobile Intel(R) Pentium(R) 4 CPU 3.06GHz Gentoo Base System version 1.12.0_pre15 ccache version 2.4 [enabled] dev-lang/python: 2.4.2 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.91.0.5 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="-O2 -march=prescott -pipe -fno-ident -g" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/init.d /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=prescott -pipe -fno-ident -g -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache digest distlocks parallel-fetch prelink sandbox sfperms splitdebug" GENTOO_MIRRORS="http://gentoo.chem.wisc.edu/gentoo/" LDFLAGS="-Wl,-O1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/dirtyepic/overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac acpi alsa audiofile avi bash-completion berkdb bitmap-fonts bzip2 cairo cdr crypt curl dbus dri dts dvd dvdr dvdread eds emboss encode exif expat fam ffmpeg firefox flac foomaticdb fortran gdbm gif glut gmp gnutls gtk gtk2 hal idn imagemagick imlib java jikes joystick jpeg jpeg2k kde kdeenablefinal lcms libg++ libwww mad mmap mmx mng mp3 mpeg mpi ncurses nsplugin ogg oggvorbis opengl pam pcmcia pcre pdflib perl pic png python qt quicktime readline ruby sdl sndfile spell sqlite sse ssl svg tcpd threads tiff truetype truetype-fonts type1-fonts udev usb vcd vorbis win32codecs xine xml xml2 xv xvid zlib elibc_glibc kernel_linux userland_GNU" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LINGUAS
Created attachment 77879 [details, diff] jpeg-mmx-0.1.6-r1.ebuild.diff
*** Bug 127831 has been marked as a duplicate of this bug. ***
Seeing same thing.
Seeing same thing.(In reply to comment #9) > Seeing same thing. > And applying patch fix it. This was much simpler though -- to test: jpeg2yuv -n 50 -I p -f 29.97 -j menu_background.jpg | mpeg2enc -n n -f 8 -o menu_background.m2v The first half of that was segfaulting. I patched jpeg-mmx with the patch attached to this bug and the segfaulting went away.
(In reply to comment #7) > Created an attachment (id=77879) [edit] > jpeg-mmx-0.1.6-r1.ebuild.diff > This patch fixed the problem for me, too. I see it's from about 5 months or so ago. Can this be applied to the mainstream ebuild so others can take advantage of it, rather than digging for a couple hours like I (and I'm sure the others) did? Thanks!
Bump, works here - can this please be committed?
Comment on attachment 77879 [details, diff] jpeg-mmx-0.1.6-r1.ebuild.diff fix the real bug, dont filter the flag
okay, so no one has volunteered to fix the real bug and we've had a relatively important package broken with default flags for 11 months. this only affects x86, so what would the arch team like done?
if you're interested in complaining, you're interested in fixing
complaining? i'm just trying to get this fixed and looking for suggestions. you don't seem interested (and that's perfectly okay), and i don't have the technical knowledge, so i'm asking my team for help. how is this complaining? what would you prefer i do instead?
Re-assigning to x86 folks. (Plus what's the point of leaving a bug sit here for one year instead of filtering the damned flag until there's a proper fix available really goes beyong me, it's not like that tons of users weren't be using -fomit-frame-pointer).
(In reply to comment #17) > Re-assigning to x86 folks. (Plus what's the point of leaving a bug sit here for > one year instead of filtering the damned flag until there's a proper fix > available really goes beyong me, it's not like that tons of users weren't be > using -fomit-frame-pointer). Sure, but we are not maintaining this ebuild (metadata says graphics which aren't on the bug).
CCed graphics as they are mentioned in metadata.xml
jpeg-mmx is dead