Since upgrading to kde 3.3.0 juk segfaults immediately after start. This is unrelated to the problem described in bug <a href="http://bugs.gentoo.org/show_bug.cgi?id=58862">id 58862</a>. I've deleted the files in ~/.kde/share/apps/juk and ~/.kde/share/config/jukrc, but this didn't solve the problem. Reproducible: Always Steps to Reproduce: 1. launch juk Actual Results: juk segfaults Expected Results: run properly Portage 2.0.50-r9 (gcc34-x86-2004.2, gcc-3.3.4, glibc-2.3.4.20040808-r0, 2.6.8-gentoo) ================================================================= System uname: 2.6.8-gentoo i686 AMD Athlon(tm) XP 2800+ Gentoo Base System version 1.5.3 distcc 2.17 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/share/config:/usr/kde/3.3/env:/usr/kde/3.3/shutdown /usr/kde/3/share/config /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/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowex X aalib acpi alsa apm arts avi berkdb cdb cdparanoia cdr crypt cups dga directfb divx4linux dvd dvdr dvdread esd flac foomaticdb ftp gcj gd gdbm gif gmp gpm gtk gtk2 gtkhtml imlib innodb java jpeg kde lcms libg++ libwww mad maildir mikmod mmap mmx motif mpeg mysql ncurses nls nptl nvidia oggvorbis opengl oss pam pdflib perl plotutils png ppds python qt quicktime readline rtc samba sdl slang spell sse ssl svga svgalib tcpd tetex theora tiff truetype unicode usb v4l2 x86 xinerama xml2 xmms xv xvid zlib"
i'm also having this problem. i compiled with gcc-3.3.3 and i get a signal 11 seg fault which produses an unuseable backtrace (because i don't have debug in my use flags probably)
can you try running it under strace or gdb and see if it gives you anything good?
I've not got debugging symbols, but I can attach my KDE Crash handler backtrace anyway, not sure how useful this is though: Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 1104414320 (LWP 20357)] 0xffffe410 in ?? () #0 0xffffe410 in ?? () #1 0xbfffee60 in ?? () #2 0x00000000 in ?? () #3 0x00000000 in ?? () #4 0x41a03fc3 in __waitpid_nocancel () from /lib/libpthread.so.0 #5 0x40ebbbae in KCrash::defaultCrashHandler () from /usr/kde/3.3/lib/libkdecore.so.4 #6 0x082e10d0 in ?? () #7 0xbfffee80 in ?? () #8 0xbfffea30 in ?? () #9 0xbfffea70 in ?? () #10 0x000000c1 in ?? () #11 0x08201418 in ?? () #12 0x082e10d0 in ?? () #13 0x08251ba0 in ?? () #14 0x00000000 in ?? () #15 0x00004fe4 in ?? () #16 0x00000400 in ?? () #17 0x00000400 in ?? () #18 0x081fe3a8 in ?? () #19 0x00000000 in ?? () #20 0x4175b218 in ?? () from /usr/qt/3/lib/libqt-mt.so.3 #21 0x082e10d0 in ?? () #22 0xbfffee80 in ?? () #23 0xbfffea88 in ?? () #24 0x412da154 in QObject::event () from /usr/qt/3/lib/libqt-mt.so.3
*shrug*
I have the same thing, gcc-3.4.1-r2 on ppc. The backtrace doesn't look too useful (I do have USE=debug through all my KDE and Qt): [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 11799)] 0x0da1a648 in waitpid () from /lib/libpthread.so.0 #0 0x0da1a648 in waitpid () from /lib/libpthread.so.0 #1 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #2 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #3 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #4 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #5 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #6 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #7 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #8 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #9 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #10 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #11 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #12 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #13 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #14 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #15 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #16 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #17 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #18 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #19 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #20 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246 #21 0x0ed21fd8 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:246
Okay, I've fixed this bug in my case. Using kdDebug statements, I tracked it down to the TagEditor::readConfig() method, where the code "TagLib::StringList::ConstIterator it = genres.begin();" causes the crash. It turns out that my taglib was linked against the libs from gcc 3.3.3, but my kde stuff was built with 3.4.1. Re-emerging taglib fixed the problem for me. My suggestion is that users look at the output of "ldd $(which juk)" to make sure that there is only one gcc version there. Of course now that I've got it running, it only plays noise, but that's another (probably ppc-specific) bug. :(
I have this problem after upgrading to GCC3.4 and removing 3.3. Removing the config files from .kde doesn't help at all. My ldd `which juk` shows: tom@tom ~ $ ldd `which juk` linux-gate.so.1 => (0xffffe000) libtunepimp.so.2 => /usr/lib/libtunepimp.so.2 (0x4002f000) libFLAC.so.4 => /usr/lib/libFLAC.so.4 (0x40092000) libmusicbrainz.so.4 => /usr/lib/libmusicbrainz.so.4 (0x400c6000) libartskde.so.1 => /usr/kde/3.3/lib/libartskde.so.1 (0x400f2000) libqtmcop.so.1 => /usr/kde/3.3/lib/libqtmcop.so.1 (0x4014e000) libsoundserver_idl.so.1 => /usr/kde/3.3/lib/libsoundserver_idl.so.1 (0x40155000) libkmedia2_idl.so.1 => /usr/kde/3.3/lib/libkmedia2_idl.so.1 (0x401b7000) libartsflow.so.1 => /usr/kde/3.3/lib/libartsflow.so.1 (0x401f8000) libesd.so.0 => /usr/lib/libesd.so.0 (0x4033d000) libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x40346000) libasound.so.2 => /usr/lib/libasound.so.2 (0x4036e000) libvorbisfile.so.3 => /usr/lib/libvorbisfile.so.3 (0x40418000) libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x4041f000) libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x40508000) libogg.so.0 => /usr/lib/libogg.so.0 (0x40530000) libmad.so.0 => /usr/lib/libmad.so.0 (0x40535000) libartsflow_idl.so.1 => /usr/kde/3.3/lib/libartsflow_idl.so.1 (0x4054b000) libmcop.so.1 => /usr/kde/3.3/lib/libmcop.so.1 (0x405f7000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x406a7000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x406ac000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x406b1000) libkio.so.4 => /usr/kde/3.3/lib/libkio.so.4 (0x4072b000) libkdeui.so.4 => /usr/kde/3.3/lib/libkdeui.so.4 (0x40a52000) libkdesu.so.4 => /usr/kde/3.3/lib/libkdesu.so.4 (0x40d12000) libkwalletclient.so.1 => /usr/kde/3.3/lib/libkwalletclient.so.1 (0x40d2b000) libkdecore.so.4 => /usr/kde/3.3/lib/libkdecore.so.4 (0x40d3b000) libDCOP.so.4 => /usr/kde/3.3/lib/libDCOP.so.4 (0x40f74000) libresolv.so.2 => /lib/libresolv.so.2 (0x40fa8000) libutil.so.1 => /lib/libutil.so.1 (0x40fba000) libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0x40fbe000) libidn.so.11 => /usr/lib/libidn.so.11 (0x40fd3000) libkdefx.so.4 => /usr/kde/3.3/lib/libkdefx.so.4 (0x41004000) libqt-mt.so.3 => /usr/qt/3/lib/libqt-mt.so.3 (0x4102f000) libmng.so.1 => /usr/lib/libmng.so.1 (0x41737000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x41792000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x417b0000) libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x417b8000) libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0x417bd000) libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x417c6000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x417d8000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x417ff000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x41867000) libdl.so.2 => /lib/libdl.so.2 (0x41886000) libpng.so.3 => /usr/lib/libpng.so.3 (0x4188b000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x418be000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x418cc000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x41997000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4199f000) libpthread.so.0 => /lib/libpthread.so.0 (0x419b7000) libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x419ca000) libz.so.1 => /lib/libz.so.1 (0x419d2000) libfam.so.0 => /usr/lib/libfam.so.0 (0x419e2000) libtag.so.1 => /usr/lib/libtag.so.1 (0x419ea000) libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.1/libstdc++.so.6 (0x41a25000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.1/libgcc_s.so.1 (0x41af5000) libm.so.6 => /lib/libm.so.6 (0x41aff000) libc.so.6 => /lib/libc.so.6 (0x41b22000) libstdc++.so.5 => /usr/lib/libstdc++-v3/libstdc++.so.5 (0x41c34000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Can anyone see anything suspicious there? Cheers
Tom, The problem is that you have both libstdc++.so.6 and libstdc++.so.5 in the list. Find out which of those libraries are using libstdc++.so.5, recompile them, and your juk should work again. I'd be interested to see if the problem is specific to taglib . . . that would be the one to try first, that's what was causing me problems.
I have the same problem, Juk crashes on startup. Running ldd gives me the following output: ldd /usr/kde/3.3/bin/juk linux-gate.so.1 => (0xffffe000) libtunepimp.so.2 => /usr/lib/libtunepimp.so.2 (0xb7f64000) libFLAC.so.4 => /usr/lib/libFLAC.so.4 (0xb7f2e000) libmusicbrainz.so.4 => /usr/lib/libmusicbrainz.so.4 (0xb7f02000) libartskde.so.1 => /usr/kde/3.3/lib/libartskde.so.1 (0xb7ea2000) libqtmcop.so.1 => /usr/kde/3.3/lib/libqtmcop.so.1 (0xb7e9b000) libsoundserver_idl.so.1 => /usr/kde/3.3/lib/libsoundserver_idl.so.1 (0xb7e35000) libkmedia2_idl.so.1 => /usr/kde/3.3/lib/libkmedia2_idl.so.1 (0xb7df3000) libartsflow.so.1 => /usr/kde/3.3/lib/libartsflow.so.1 (0xb7c99000) libesd.so.0 => /usr/lib/libesd.so.0 (0xb7c91000) libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0xb7c68000) libvorbisfile.so.3 => /usr/lib/libvorbisfile.so.3 (0xb7c61000) libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0xb7b63000) libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb7b3b000) libogg.so.0 => /usr/lib/libogg.so.0 (0xb7b35000) libmad.so.0 => /usr/lib/libmad.so.0 (0xb7b1f000) libartsflow_idl.so.1 => /usr/kde/3.3/lib/libartsflow_idl.so.1 (0xb7a6c000) libmcop.so.1 => /usr/kde/3.3/lib/libmcop.so.1 (0xb79b5000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb79b1000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb79ac000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb791f000) libkio.so.4 => /usr/kde/3.3/lib/libkio.so.4 (0xb75ac000) libkdeui.so.4 => /usr/kde/3.3/lib/libkdeui.so.4 (0xb72ca000) libkdesu.so.4 => /usr/kde/3.3/lib/libkdesu.so.4 (0xb72ae000) libkwalletclient.so.1 => /usr/kde/3.3/lib/libkwalletclient.so.1 (0xb729e000) libkdecore.so.4 => /usr/kde/3.3/lib/libkdecore.so.4 (0xb703c000) libDCOP.so.4 => /usr/kde/3.3/lib/libDCOP.so.4 (0xb7004000) libresolv.so.2 => /lib/libresolv.so.2 (0xb6ff0000) libutil.so.1 => /lib/libutil.so.1 (0xb6fec000) libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0xb6fd5000) libidn.so.11 => /usr/lib/libidn.so.11 (0xb6fa6000) libkdefx.so.4 => /usr/kde/3.3/lib/libkdefx.so.4 (0xb6f79000) libqt-mt.so.3 => /usr/qt/3/lib/libqt-mt.so.3 (0xb6871000) libmng.so.1 => /usr/lib/libmng.so.1 (0xb6815000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb67f7000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0xb67ef000) libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0xb67eb000) libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0xb67e2000) libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0xb67ce000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb67a5000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6740000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb6720000) libdl.so.2 => /lib/libdl.so.2 (0xb671c000) libpng.so.3 => /usr/lib/libpng.so.3 (0xb66e8000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb66d8000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb660a000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb6601000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb65ea000) libpthread.so.0 => /lib/libpthread.so.0 (0xb6598000) libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0xb6590000) libz.so.1 => /lib/libz.so.1 (0xb657e000) libfam.so.0 => /usr/lib/libfam.so.0 (0xb6576000) libtag.so.1 => /usr/lib/libtag.so.1 (0xb652d000) libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.2/libstdc++.so.6 (0xb645b000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.2/libgcc_s.so.1 (0xb6452000) libm.so.6 => /lib/libm.so.6 (0xb642f000) libc.so.6 => /lib/libc.so.6 (0xb6316000) libstdc++.so.5 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5 (0xb624d000) /lib/ld-linux.so.2 (0xb7feb000) This makes me think it was a problem with upgrading from gcc 3.3 to gcc 3.4. I recompiled taglib and juk still crashes. How do I figure out what libraries are pulling in libstdc++.so.5 so I can get rid of them. Aaron
Something like this should give you a hint: grep -l i686-pc-linux-gnu/3.3.4/libstdc++.la /usr/lib/*.la /usr/kde/3.3/lib/*.la /usr/kde/3.3/lib/kde3/*.la
The mixing of libstdc++.so.5 and .6 caused by linking an library compiled with gcc 3.3 and the program compiled with gcc 3.4 will bring to these crashes and errors. I've opened a thread on this in the italian forum: http://forums.gentoo.org/viewtopic.php?t=242168 A simple command to launch for fixing will be: (better than an emerge -e world) 1) assure that you are using gcc-3.4.x. 2) rm ~/.revdep-rebuild* revdep-rebuild -X --soname libstdc++.so.5 This will find all the libraries/programs linked to libstdc++.so.5 and recompile them with gcc 3.4.2. if you get some errors, try launching emerge by hand editing the gived emerge command and removing "--oneshot" and the forcing to that version (=foo-ver). But remember to not remove any ebuild from the emerge command because the order is important, as you need to rebuild all in the dependencies order. I hope this will help.
Thanks for the help, the program that was causing juke to crash was tunepimp or libtunepimp.so.2 more specifically.
Sorry for posting two comments on the same bug, but I was having a problem when I upgraded gcc from the 3.3 series to the 3.4 series. libtunepimp was still compiled and depened on libstdc++.so.5. To fix it I recompiled musicbrainz and tunepimp
Hi Simone Gotti, you worte an workaround for this bug: ####################### A simple command to launch for fixing will be: (better than an emerge -e world) 1) assure that you are using gcc-3.4.x. 2) rm ~/.revdep-rebuild* revdep-rebuild -X --soname libstdc++.so.5 ####################### If I set-up the command "revdep-rebuild -X --soname libstdc++.so.5" I get the following output: /opt/blackdown-jre-1.4.1/plugin/i386/netscape4/javaplugin.so -> dev-java/blackdown-jre done. (/root/.revdep-rebuild_fb248503.4_packages_raw, /root/.revdep-rebuild_fb248503.4_package_owners) Cleaning list of packages to rebuild... done. (/root/.revdep-rebuild_fb248503.5_packages) Evaluating package order... Warning: Failed to resolve package order. Will merge in "random" order! Possible reasons: - Some ebuilds are no more in portage tree. - Some ebuilds are masked, try to change ACCEPT_KEYWORDS="~<your platform>" and/or use /etc/portage/package.unmask .....ln: accessing `/root/.revdep-rebuild_fb248503.4_ebuilds': No such file or directory done. (/root/.revdep-rebuild_fb248503.5_order) cat: /root/.revdep-rebuild_fb248503.5_order: No such file or directory There are no dynamic links to libstdc++.so.5... All done. bash-2.05b# It talled me that libstdc++.so.5 where not found. Do I something wrong? Thx, Benjamin
simply. This isn't your problem. This trick, like explained, is for who moves from gcc 3.3 to gcc 3.4 and don't want to rebuild EVERY package, but only the ones that uses the old libstdc++.so.5. The unique program using it was the java one as its a binary package (so this is normal).
I think this can be closed now...
*** Bug 82083 has been marked as a duplicate of this bug. ***
*** Bug 97028 has been marked as a duplicate of this bug. ***
*** Bug 98295 has been marked as a duplicate of this bug. ***
*** Bug 98784 has been marked as a duplicate of this bug. ***
*** Bug 114863 has been marked as a duplicate of this bug. ***
*** Bug 115842 has been marked as a duplicate of this bug. ***
*** Bug 117681 has been marked as a duplicate of this bug. ***
*** Bug 118171 has been marked as a duplicate of this bug. ***
*** Bug 120286 has been marked as a duplicate of this bug. ***
*** Bug 121894 has been marked as a duplicate of this bug. ***
*** Bug 123144 has been marked as a duplicate of this bug. ***
*** Bug 130421 has been marked as a duplicate of this bug. ***
*** Bug 134447 has been marked as a duplicate of this bug. ***
*** Bug 138706 has been marked as a duplicate of this bug. ***
*** Bug 149821 has been marked as a duplicate of this bug. ***
*** Bug 156500 has been marked as a duplicate of this bug. ***
