I compiled and emerged gxine on my AMD64 (Athlon64 3200+) using GCC 3.4.3 today, and found I could not make it start. Since Xine-ui compiles and works fine, it lead me to believe that xine-lib was fine, and that this is the fault of gxine. I went to see if my CFLAGS were the problem, and put them down to nothing. Even with no optimization, it continued to segfault. I don't know what else to do. Strace's output was confusing, as it seems to just load all the plugins and then die a horrible death. Reproducible: Always Steps to Reproduce: 1. 2. 3. sakaki sakaki # emerge info Portage 2.0.51-r15 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.10-gentoo-r6 x86_64) ================================================================= System uname: 2.6.10-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.9 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Jan 30 2005, 02:01:44)] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon64 -fomit-frame-pointer -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon64 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox" 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="X a52 aac aalib acpi aim alsa amd64 apache2 artworkextra audiofile avi bash-completion berkdb bitmap-fonts bmp bonobo bzip2 bzlib canna cdda cddb cdio cdparanoia cdr cjk crypt cups curl dba dbus dga dio divx4linux dv dvd dvdr dvdread emul-linux-x86 encode esd ethereal exif faac faad fam fame ffmpeg flac font-server foomaticdb freetype ftp gd gd-external gdbm gif gnome gnutls gpm gstreamer gtk gtk2 gtkhtml gzip hal httpd icq ieee1394 imagemagick imap imlib inifile ipv6 jabber java jikes jpeg lcms libcaca libclamav libwww live lzo mad maildir matroska memlimit mikmod mime ming mjpeg mmap mng mozilla moznomail mozsvg mp3 mpeg mpeg2 mpm-prefork multilib mysql ncurses network nls nptl nptlonly nvidia oav offensive ogg oggvorbis openal opengl pam pcre perl php pic pie png python quicktime readline real ruby samba sasl sblive scanner sdl sharedmem sndfile sockets sox speex spell sqlite ssl stream svg tcltk tcpd theora tiff truetype truetype-fonts type1-fonts usb utf8 vcd vidix vorbis wmf wxwindows xanim xine xml2 xmms xosd xpm xprint xv xvid xvmc yv12 zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
not gnome
Created attachment 50424 [details] strace output
Well, I figured since gxine apart of the whole 'GNOME Integration' scheme, I'd put it under GNOME. I'll change it to 'Applications' if it's more suitable.
Seams to be a suspicious problem on amd64 - Got same core dump, reproducible gdb /usr/bin/gxine core has shown #0 0x0000000000458224 in js_FinishAtomState () No other usefule information out of that (no bt) - Running directly with gdb: > gdb /usr/bin/gxine ... (gdb) r => Success, suddenly it runs Seams a matter of mutation testing, whats the difference between running inside gdb and outside? Alasdair, can you verify that running in gdb? Thanks.
Tried this with upstream source, ./configure and install in /usr/local. No difference, except inside gdb we now have: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 18512)] 0x0000000000449864 in JS_ArenaAllocate () (gdb) bt #0 0x0000000000449864 in JS_ArenaAllocate () #1 0x0000000000472272 in gc_new_arena () #2 0x0000000000472758 in js_AllocGCThing () #3 0x0000000000460b1c in js_NewString () #4 0x0000000000460d82 in js_NewStringCopyN () #5 0x0000000000470b59 in js_AtomizeString () #6 0x0000000000470cbc in js_Atomize () #7 0x000000000046fb88 in js_InitPinnedAtoms () #8 0x000000000046f9b1 in js_InitAtomState () #9 0x000000000048c9a1 in js_NewContext () #10 0x000000000043775b in JS_NewContext () #11 0x000000000042c0ba in se_new () #12 0x0000000000418894 in engine_init () #13 0x000000000041be12 in main () (gdb) l 1 /var/tmp/portage/glibc-2.3.4.20041102/work/build-default-x86_64-pc-linux-gnu-linuxthreads/csu/crti.S: No such file or directory. in /var/tmp/portage/glibc-2.3.4.20041102/work/build-default-x86_64-pc-linux-gnu-linuxthreads/csu/crti.S (gdb)
This seams to, that this app is not 64-bit clean. Following bt at 13th hit on js_NewString (gdb) bt #0 js_AllocGCThing (cx=0x789190, flags=1) at jsgc.c:490 #1 0x0000000000460b1c in js_NewString (cx=0x789190, chars=0x78da40, length=4, gcflag=0) at jsstr.c:2346 #2 0x0000000000460d82 in js_NewStringCopyN (cx=0x789190, s=0x7fbffff010, n=4, gcflag=0) at jsstr.c:2457 #3 0x0000000000470b59 in js_AtomizeString (cx=0x789190, str=0x7fbffff060, flags=129) at jsatom.c:575 #4 0x0000000000470cbc in js_Atomize (cx=0x789190, bytes=0x4c9a44 "Call", length=4, flags=1) at jsatom.c:646 #5 0x000000000046fc0a in js_InitPinnedAtoms (cx=0x789190, state=0x783450) at jsatom.c:261 #6 0x000000000046f9b1 in js_InitAtomState (cx=0x789190, state=0x783450) at jsatom.c:232 #7 0x000000000048c9a1 in js_NewContext (rt=0x7833a0, stackChunkSize=4096) at jscntxt.c:128 #8 0x000000000043775b in JS_NewContext (rt=0x7833a0, stackChunkSize=4096) at jsapi.c:886 #9 0x000000000042c0ba in se_new () at script_engine.c:758 #10 0x0000000000418894 in engine_init () at engine.c:123 #11 0x000000000041be12 in main (argc=1, argv=0x7fbffff268) at main.c:293 (gdb) p *pool->current $14 = {next = 0x5, base = 7920032, limit = 7, avail = 7920112} (gdb) Actually, it later breaks on pool->current->next which should be NULL or point to a valid memory address. Similiar problems on ppc64? Fix all relatated warnings, e.g. jsemit.c:1880: warning: cast from pointer to integer of different size Remove ">/dev/null 2>&1" from build system, so we get early warnings. Add -Wuninitialized ... Hard-mask this 0.4.1 version out for amd64
In CVS ChankeLog for 0.42 following remark at the very beginning: ! Use external JS lib by default (if available). If you're using amd64, you want this, I'm told. So, mask-out this package for amd64 (or all 64-bit platforms), the (internal) JavaScript Interpreter is broken on 64-bit. Or make an ebuild for libsmjs or libjs, smjs/jsapi.h or js/jsapi.h needed, ./configure --with-external-spidermonkey and this package depend on it.
We need dev-lang/spidermonkey-1.5_rc6-r1 fixed with the PPC patch from Bug #81473 and added keyword ~amd64 to that.
Created attachment 51712 [details, diff] gxine-0.4.1.ebuild.diff Please apply attached patch to gxine-0.4.1.ebuild. Tested and works.
Fixed with 0.4.3 version of gxine.
*** Bug 66746 has been marked as a duplicate of this bug. ***