Version: cvs (using KDE Devel) Installed from: Compiled sources Compiler: g++ 3.2 OS: Linux I exited my KDE session earlier today. Loged back in and now JuK crashes on startup with the following backtrace: #3 0x409ae657 in KCrash::defaultCrashHandler(int) (sig=6) at kcrash.cpp:235 #4 0x4142c9d8 in sigaction () from /lib/libc.so.6 #5 0x4139e521 in raise () from /lib/libpthread.so.0 #6 0x4142d986 in abort () from /lib/libc.so.6 #7 0x40b65994 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.5 #8 0x40b659d8 in std::terminate() () from /usr/lib/libstdc++.so.5 #9 0x40b65b25 in __cxa_throw () from /usr/lib/libstdc++.so.5 #10 0x40b65cd5 in operator new(unsigned) () from /usr/lib/libstdc++.so.5 #11 0x40b65da7 in operator new[](unsigned) () from /usr/lib/libstdc++.so.5 #12 0x411060c9 in operator>>(QDataStream&, QString&) (s=@0xbffff650, str=@0x8232b90) at tools/qstring.cpp:17753 #13 0x08075141 in CachedTag::read(QDataStream&) (this=0x8232b50, s=@0xbffff650) at cachedtag.cpp:181 #14 0x0807520e in operator>>(QDataStream&, CachedTag&) (s=@0xbffff650, t=@0x8232b50) at cachedtag.cpp:223 #15 0x0808e94a in Cache::load() (this=0x820c010) at cache.cpp:89 #16 0x0808e51c in Cache::instance() () at cache.cpp:34 #17 0x08077f6d in CollectionList::initialize(QWidget*, bool) ( parent=0x81daf38, restoreOnLoad=true) at collectionlist.cpp:46 #18 0x0808401a in PlaylistSplitter::setupLayout() (this=0x81d1470) at playlistsplitter.cpp:380 #19 0x080829b6 in PlaylistSplitter (this=0x81d1470, parent=0x81af0a0, restore=true, name=0x80a77d9 "playlistSplitter") at playlistsplitter.cpp:66 #20 0x0809435b in JuK::setupLayout() (this=0x81af0a0) at juk.cpp:85 #21 0x08093fad in JuK (this=0x81af0a0, parent=0x0, name=0x0) at juk.cpp:61 #22 0x0809976f in main (argc=7, argv=0xbffff9c4) at main.cpp:71
Subject: Re: Crash on starting juk Well, somehow your cache got corrupted. I can reproduce something similar if I intentionally corrupt my cache, but I've never had that hapen in real usage (this is the first report of such). So, here's the question -- do you know of an easy way to check a QDataStream for validity before trying to read it? The only way that I know of corrupting it in real use is killing JuK while it's exiting. For a quick fix you can rm your $KDEHOME/share/apps/juk/cache, but you might want to save a copy for later debugging. Also, could you send me that file? I'd like to see how / where it's corrupted.
Subject: Re: Crash on starting juk Ok, I just closed this because I'm pretty sure I spotted it and fixed it. If you're running HEAD can you give it a try? Otherwise I can send you a patch againt 1.1.
Subject: Re: Crash on starting juk On Tuesday 01 April 2003 20:34, you wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=56733 > > > > > ------- Additional Comments From wheeler@kde.org 2003-04-02 03:34 > ------- Subject: Re: Crash on starting juk > > Ok, I just closed this because I'm pretty sure I spotted it and fixed > it. If you're running HEAD can you give it a try? Otherwise I can > send you a patch againt 1.1. Sure you got the right bug there? I think you fixed 56687 and not this one. There's no way of testing qdatastream directly for validity but what could be done is creating an empty "invalid" file that would be deleted when cache would have been completely written to "cache" file. If JuK on startup would detect existence of that file it would regenerate the cache. Anyway, here's the cache file you asked for : Created an attachment (id=1288) cache
Subject: Re: Crash on starting juk Oops. ;-) Correcting that now... On Wednesday 02 April 2003 3:53, Zack Rusin wrote: > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > http://bugs.kde.org/show_bug.cgi?id=56733 > > > > > ------- Additional Comments From zack@kde.org 2003-04-02 03:53 ------- > Subject: Re: Crash on starting juk > > On Tuesday 01 April 2003 20:34, you wrote: > > ------- You are receiving this mail because: ------- > > You reported the bug, or are watching the reporter. > > > > http://bugs.kde.org/show_bug.cgi?id=56733 > > > > > > > > > > ------- Additional Comments From wheeler@kde.org 2003-04-02 03:34 > > ------- Subject: Re: Crash on starting juk > > > > Ok, I just closed this because I'm pretty sure I spotted it and fixed > > it. If you're running HEAD can you give it a try? Otherwise I can > > send you a patch againt 1.1. > > Sure you got the right bug there? I think you fixed 56687 and not this > one. There's no way of testing qdatastream directly for validity but > what could be done is creating an empty "invalid" file that would be > deleted when cache would have been completely written to "cache" file. > If JuK on startup would detect existence of that file it would > regenerate the cache. > Anyway, here's the cache file you asked for : > > > > > Created an attachment (id=1288) > --> (http://bugs.kde.org/attachment.cgi?id=1288&action=view) > cache >
Subject: Re: Crash on starting juk Ok, what Maks suggested was saving a checksum of the file and comparing against that. I presumed that the cache would be lost in the case that it was invalid, but well, that would be better than segfaulting. :-) I'll see about implementing that in the next few days. -Scott
This just happened to me. Juk stayed in the system tray after I right clicked on it and told it to quit. I rebooted, and now Juk crashes on start with a "Items Loaded: 0" splashscreen. I don't know if this is the same problem, but I will backup my cache and delete it. I will be willing to send it to anyone that needs to analyze it. Here's the backtrace: (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 16384 (LWP 1459)] (no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... 0x415d4579 in wait4 () from /lib/libc.so.6 #0 0x415d4579 in wait4 () from /lib/libc.so.6 #1 0x41651214 in __DTOR_END__ () from /lib/libc.so.6 #2 0x414bdaa3 in waitpid () from /lib/libpthread.so.0 #3 0x40b041fd in KCrash::defaultCrashHandler(int) () from /usr/kde/3.1/lib/libkdecore.so.4 #4 <signal handler called> #5 0x4154fcf1 in kill () from /lib/libc.so.6 #6 0x414bbb2d in pthread_kill () from /lib/libpthread.so.0 #7 0x414bbe4b in raise () from /lib/libpthread.so.0 #8 0x4155117c in abort () from /lib/libc.so.6 #9 0x40cd18db in __cxxabiv1::__terminate(void (*)()) () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libstdc++.so.5 #10 0x40cd191c in std::terminate() () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libstdc++.so.5 #11 0x40cd1ac6 in __cxa_throw () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libstdc++.so.5 #12 0x40cd1d23 in operator new(unsigned) () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libstdc++.so.5 #13 0x40cd1e75 in operator new[](unsigned) () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libstdc++.so.5 #14 0x411e56d5 in operator>>(QDataStream&, QString&) () from /usr/qt/3/lib/libqt-mt.so.3 #15 0x0806bca3 in QString::~QString() () #16 0x08083c2b in KCompletionBase::completionMode() const () #17 0x08083794 in KCompletionBase::completionMode() const () #18 0x0806eded in QString::~QString() () #19 0x0807953c in QPtrList<QListViewItem>::deleteItem(void*) () #20 0x08077653 in QPtrList<QListViewItem>::deleteItem(void*) () #21 0x08087a78 in QSlider::metaObject() const () #22 0x08087913 in QSlider::metaObject() const () #23 0x0808b9c9 in QPtrList<char>::deleteItem(void*) () #24 0x4153bdc4 in __libc_start_main () from /lib/libc.so.6
Created attachment 1477 [details] cache from juk that crashes on startup This is the cache from Juk that crashes on startup. I will delete this and try Juk again. I am running Juk 1.1 on KDE 3.1.1a on Gentoo.
This happens to me every time I try to run juk, after having run it successfully, and then Quit. Removing the cache file allows it to run once, but the next time it crashes. Same backtrace. I should also mention that it uses up all available memory before it crashes. I'm running orth's CVS build for Debian from yesterday (4:3.2.0-0+cvs20030529+orth).
Hi There, I have the same problem.. running from debian packages (4:3.2.0-0+cvs20030529+orth) Happens every time I try to load Juk for the second time (after adding files to the play list) Removing the cache file does help. This happens no matter what mp3s I load into the play list. Perhaps it would be a good idea to figure out why the cache file is corrupt, not to try and fix it once it is corrupt? Thanks heaps! David
Just a note -- this bug is mostly fixed; I've been waiting to close it until I add some Extra Paranoid (tm) checking, but this shouldn't happen in general at the present. The last three people who have reported it are all using the Debian CVS packages, so I assume this to be a problem with those packages rather than JuK in it's current status.
Okay, this happens when I build with --enable-final ... the cache seems to be corrupted for some reason. I rebuilt juk without --enable-final and it's now fixed, but if you already have an existing song cache, it will still crash, you will have to remove the old one (rm ~/.kde/share/apps/juk/cache) and restart juk. Make sure you upgrade to at least juk 20030531
I've got the same problem - well, with a corrupted cache - Debian Woody, gcc-2.95, KDE 3.1.2 I'm NOT using the Debian CVS packages for juk - I got it and compiled it myself ;) BUT I backed up the cache, restarted juk, and it was fine. Put the corrupted cache back, and it STILL works fine.. :? David
Subject: Re: Crash on starting juk > ------- Additional Comments From dmp@davidmpye.dyndns.org 2003-06-23 20:28 ------- > I've got the same problem - well, with a corrupted cache - Debian Woody, gcc-2.95, KDE > 3.1.2 > > I'm NOT using the Debian CVS packages for juk - I got it and compiled it myself ;) > > BUT I backed up the cache, restarted juk, and it was fine. Put the corrupted cache back, > and it STILL works fine.. :? Works fine once, or the cache gets corrupted and then works again for subsequent starts? Are you using --enable-final? Is this JuK from CVS or 1.1?
*** Bug 59660 has been marked as a duplicate of this bug. ***
Subject: kdemultimedia/juk CVS commit by wheeler: Checksum the cache on write and compare to that value on read. With this I'm closing the "crash on startup" bug since this should fix things. CCMAIL:56733-done@bugs.kde.org M +39 -6 cache.cpp 1.13 --- kdemultimedia/juk/cache.cpp #1.12:1.13 @@ -17,7 +17,11 @@ #include <kstandarddirs.h> +#include <kmessagebox.h> +#include <kconfig.h> +#include <klocale.h> #include <kdebug.h> #include <qdir.h> +#include <qbuffer.h> #include "cache.h" @@ -49,5 +53,6 @@ void Cache::save() return; - QDataStream s(&f); + QByteArray data; + QDataStream s(data, IO_WriteOnly); for(QDictIterator<Tag>it(*this); it.current(); ++it) { @@ -56,7 +61,19 @@ void Cache::save() } + f.writeBlock(data); f.close(); - QDir dir(dirName); - dir.rename("cache.new", "cache"); + + QDir(dirName).rename("cache.new", "cache"); + + // Store the checksum so that later we can make sure that things are ok. + + int checksum = qChecksum(data.data(), data.size()); + + KConfig *config = KGlobal::config(); + { + KConfigGroupSaver saver(config, "Cache"); + config->writeEntry("Checksum", checksum); + } + config->sync(); } @@ -84,5 +101,23 @@ void Cache::load() return; - QDataStream s(&f); + QByteArray data = f.readAll(); + f.close(); + + // Compare the checksum of the data to the one stored in the config file to + // make sure that our cache isn't corrupt. + + int checksum; + KConfig *config = KGlobal::config(); + { + KConfigGroupSaver saver(config, "Cache"); + checksum = config->readNumEntry("Checksum", -1); + } + if(checksum >= 0 && checksum != qChecksum(data.data(), data.size())) { + KMessageBox::sorry(0, i18n("The music data cache has been corrupted. JuK " + "needs to rescan it now. This may take some time.")); + return; + } + + QDataStream s(data, IO_ReadOnly); while(!s.atEnd()) { @@ -100,5 +135,3 @@ void Cache::load() // CollectionListItem constructor. } - - f.close(); }
Hmm - I'm expirencing this to... KDE 3.2.2, Gentoo... First it just crashed instantly. After deleting the cache file it said 'Items loaded: ...' (counting up to ~1100, the number of files in my music dir, _then_ failed... I then deleted the playlist file too - now it doesn't coun't the files in my music dir but just failes... I then installed JuK 'standalone' from Gentoo's Portage, which - after deleting 4 now corrupt files - workes fine until reboot, then crashes and throws away the playlist + cache Any good ideas? (sorry I can't attach the cache files 'cus I deleted it) Morten / Denmark
Anybody able to help me? I still encounters this bug... backtrace (possible not complete - didn't compile with debug set) --- (no debugging symbols found)...Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... [[[ and so on for ~10-15 lines ]]] (no debugging symbols found)...0x419d9a28 in waitpid () from /lib/libpthread.so.0 #0 0x419d9a28 in waitpid () from /lib/libpthread.so.0 #1 0x40e37034 in ?? () from /usr/kde/3.2/lib/libkdecore.so.4 #2 0x40d70154 in KCrash::defaultCrashHandler(int) () from /usr/kde/3.2/lib/libkdecore.so.4 #3 0x419d86d5 in __pthread_clock_settime () from /lib/libpthread.so.0 #4 <signal handler called> #5 0x4187d0a3 in std::locale::_Impl::_M_remove_reference() () from /usr/lib/libstdc++.so.3 #6 0x4186d306 in std::locale::operator=(std::locale const&) () from /usr/lib/libstdc++.so.3 #7 0x4186c635 in std::ios_base::_M_init() () from /usr/lib/libstdc++.so.3 #8 0x418925f3 in std::basic_ios<char, std::char_traits<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*) () from /usr/lib/libstdc++.so.3 #9 0x405c65da in Arts::MCOPConfig::readEntry(std::string const&, std::string const&) () from /usr/kde/3.2/lib/libmcop.so.1 #10 0x405ba445 in Arts::MCOPUtils::readConfigEntry(std::string const&, std::string const&) () from /usr/kde/3.2/lib/libmcop.so.1 #11 0x40598211 in Arts::Dispatcher::Dispatcher(Arts::IOManager*, Arts::Dispatcher::StartServer) () from /usr/kde/3.2/lib/libmcop.so.1 #12 0x400c935f in KArtsDispatcher::KArtsDispatcher(QObject*, char const*) () from /usr/kde/3.2/lib/libartskde.so.1 #13 0x08066c81 in QWidget::setWFlags(unsigned) () #14 0x08066144 in QWidget::setWFlags(unsigned) () #15 0x0808d674 in KCompletionBase::completionMode() const () #16 0x08094fac in QWheelEvent::~QWheelEvent() () #17 0x0809205f in QWheelEvent::~QWheelEvent() () #18 0x08098299 in KMainWindow::readProperties(KConfig*) () #19 0x41ae8c64 in __libc_start_main () from /lib/libc.so.6 #20 0x080650f1 in ?? () --- --- version --- bash-2.05b# /usr/kde/3.2/bin/juk --version Qt: 3.3.0 KDE: 3.2.2 JuK: 2.0.1 --- I now have a cache file - I've attached it... I have compiled it (kdemultimedia) now - 2 times using standard Gentoo Portage, third time with Unsermake Morten Fangel / Denmark
Created attachment 6110 [details] Cache from craching JuK 2.0.1
Your cache works fine for me with both the current CVS and KDE 3.2 versions of JuK. Without a valid backtrace there's not much that I can do to help. (In fact the crash that you're reporting probably isn't related to this bug report.)
I got the same problem which is described exactly as above. So it seems that this problem is solved. Thanks. I just want to ask an i18n problem, I have mp3s with chinese GB2312 coding, is it possible to read them in JuK. JuK seems to just handle utf-8 characters.
Hi am using fedora3 and have installed kde3.4. But my juk is getting crashed when i start it giving this backtrace.. Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1208863040 (LWP 9213)] [KCrash handler] #4 0x0029a412 in TagLib::String::String () from /usr/lib/libtag.so.1 #5 0x080dbcf8 in TagLib::List<TagLib::String>::detach () #6 0x080dbd38 in TagLib::List<TagLib::String>::begin () #7 0x080fee61 in TagEditor::readConfig () #8 0x080ff1c5 in TagEditor::TagEditor () #9 0x080ee1b6 in PlaylistSplitter::setupLayout () #10 0x080eed09 in PlaylistSplitter::PlaylistSplitter () #11 0x080bf30e in JuK::setupLayout () #12 0x080c2451 in JuK::JuK () #13 0x080c5c03 in main ()
For me, JuK crashes upon program start-up with Signal 11 (SIGSEGV). My guess is that I installed something new that interferes with JuK's operation. Anyway, here is the backtrace (I hope it has something useful in it). (no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (no debugging symbols found) `system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols. (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1247410560 (LWP 14686)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [KCrash handler] #3 0xb7c617f0 in std::_Rb_tree<std::string, std::pair<std::string const, std::string>, std::_Select1st<std::pair<std::string const, std::string> >, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > >::lower_bound () from /usr/lib/libtunepimp.so.2 #4 0xb6cc54d1 in Arts::Connection::setHints () from /usr/lib/libmcop.so.1 #5 0xb6ce2fb1 in Arts::Dispatcher::handle () from /usr/lib/libmcop.so.1 #6 0xb6cc52c1 in Arts::Connection::receive () from /usr/lib/libmcop.so.1 #7 0xb6cef0ce in Arts::SocketConnection::notifyIO () from /usr/lib/libmcop.so.1 #8 0xb6ce574e in Arts::StdIOManager::processOneEvent () from /usr/lib/libmcop.so.1 #9 0xb6071426 in Arts::QIOManager::processOneEvent () from /usr/lib/libqtmcop.so.1 #10 0xb6ce3c58 in Arts::Dispatcher::connectUrl () from /usr/lib/libmcop.so.1 #11 0xb6ce3a7f in Arts::Dispatcher::connectObjectRemote () from /usr/lib/libmcop.so.1 #12 0xb6fb7647 in Arts::SoundServerV2_base::_fromReference () from /usr/lib/libsoundserver_idl.so.1 #13 0xb6fb7231 in Arts::SoundServerV2_base::_fromString () from /usr/lib/libsoundserver_idl.so.1 #14 0xb7534d43 in KArtsServer::server () from /usr/lib/libartskde.so.1 #15 0xb7522368 in KDE::PlayObjectFactory::PlayObjectFactory () from /usr/lib/libartskde.so.1 #16 0x080a029f in ArtsPlayer::setupArtsObjects () #17 0x080a04c1 in ArtsPlayer::setupPlayer () #18 0x0809f328 in ArtsPlayer::ArtsPlayer () #19 0x080ce16e in QValueListPrivate<HistoryItem::Item>::~QValueListPrivate () #20 0x080cf800 in PlayerManager::setOutput () #21 0x080cfeed in PlayerManager::setup () #22 0x080cfa4d in PlayerManager::player () #23 0x080ce494 in PlayerManager::playing () #24 0x080fbe9f in SystemTray::SystemTray () #25 0x080c3404 in JuK::setupSystemTray () #26 0x080c1950 in JuK::JuK () #27 0x080c8b1f in main ()