Here's the backtrace: Thread 1 (Thread 0x7f7df7f257c0 (LWP 17722)): [KCrash Handler] #6 0x00007f7d782e6d16 in ?? () from /usr/lib/libnepomukcore.so.4abi1 #7 0x00007f7d782faced in Nepomuk2::Resource::determineFinalResourceData() const () from /usr/lib/libnepomukcore.so.4abi1 #8 0x00007f7d782fb134 in Nepomuk2::Resource::property(QUrl const&) const () from /usr/lib/libnepomukcore.so.4abi1 #9 0x00007f7d786109d4 in Meta::NepomukTrack::lastPlayed (this=0x7f7dd008e070) at /home/mark/Devel/src/amarok/src/core-impl/collections/nepomukcollection/meta/NepomukTrack.cpp:302 #10 0x00007f7d78610a83 in non-virtual thunk to Meta::NepomukTrack::lastPlayed() const (this=0x7f7dd008e088) at /home/mark/Devel/src/amarok/src/core-impl/collections/nepomukcollection/meta/NepomukTrack.cpp:303 #11 0x00007f7e0cd26f4a in RecentlyPlayedListWidget::updateWidget (this=0x1aa78a0) at /home/mark/Devel/src/amarok/src/context/widgets/RecentlyPlayedListWidget.cpp:84 #12 0x00007f7e0cd27d67 in RecentlyPlayedListWidget::trackChanged (this=0x1aa78a0, track=...) at /home/mark/Devel/src/amarok/src/context/widgets/RecentlyPlayedListWidget.cpp:154 #13 0x00007f7e0cd284d1 in RecentlyPlayedListWidget::qt_static_metacall (_o=0x1aa78a0, _c=QMetaObject::InvokeMetaMethod, _id=1, _a=0x7fffbaed1880) at /home/mark/Devel/build/amarok/src/RecentlyPlayedListWidget.moc:58 #14 0x00007f7e09e200ef in QMetaObject::activate (sender=0xee8390, m=<optimized out>, local_signal_index=<optimized out>, argv=0x7fffbaed1880) at kernel/qobject.cpp:3539 #15 0x00007f7e0d151f84 in EngineController::trackChanged (this=0xee8390, _t1=...) at /home/mark/Devel/build/amarok/src/EngineController.moc:283 #16 0x00007f7e0d151e24 in EngineController::endSession (this=0xee8390) at /home/mark/Devel/src/amarok/src/EngineController.cpp:342 #17 0x00007f7e0d1442fe in App::~App (this=0x7fffbaed2118) at /home/mark/Devel/src/amarok/src/App.cpp:206 #18 0x000000000040f948 in main (argc=4, argv=0x7fffbaed34b8) at /home/mark/Devel/src/amarok/src/main.cpp:330 (I've also had a better backtrace, but can't seem to find it ATM) Basically what happens is that on line 699 of resource.cpp: if (!m_data->uri().isEmpty()) { m_data happens to be null. Reproducible: Sometimes Steps to Reproduce: 1. Create some resources. 2. Try to get some of their property()ies. 3. ???? 4. PROFIT^WCRASH Actual Results: crash! Expected Results: no crash.
Hey Edward, could you please install the nepomuk-core debugging symbols. It would be nice to know exactly where it is crashing. Thanks!
I do have the debug symbols, and I've traced it to Resource::m_data being null in the first line of Nepomuk2::Resource::determineFinalResourceData. The backtrace I've posted in the bug is not mine but markey's (I forgot to save the one I obtained). If I reproduce the crash, I'll attach a better backtrace.
Bug 320978 contains a good backtrace of the crash.
*** Bug 320978 has been marked as a duplicate of this bug. ***
*** Bug 319481 has been marked as a duplicate of this bug. ***
Git commit 9b7abb202407bc42e3f711aa0f51a33ede80a3bc by Simeon Bird. Committed on 06/06/2013 at 01:22. Pushed by sbird into branch 'master'. Resource: Null guards for m_data It is possible, during shutdown, for m_data to be null briefly (see ResourceManager::cleanupResources). If a property were accessed during this time, we could crash. The patch checks whether m_data is null in various functions, and returns empty items if so. Related: bug 319481 REVIEW: 110877 M +57 -14 libnepomukcore/resource/resource.cpp http://commits.kde.org/nepomuk-core/9b7abb202407bc42e3f711aa0f51a33ede80a3bc