Summary: | nepomuk regression just after 4.8.3. | ||
---|---|---|---|
Product: | [Unmaintained] nepomuk | Reporter: | Hussam Al-Tayeb <ht990332> |
Component: | general | Assignee: | Sebastian Trueg <trueg> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | aacid, alejandronova, alien, cfeck, desintegr, dilfridge, eli, eric.lemoussu, franz.trischberger, ht990332, hubn3rd, korgens, manfred.kitzbichler, me, modax, moro.engelhardt, rdieter, red4fireluv04, scarpino, than, wikt.sztw+kdebugs, zerg |
Priority: | NOR | Keywords: | regression |
Version: | 4.8 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Bug Depends on: | |||
Bug Blocks: | 277705 |
Description
Hussam Al-Tayeb
2012-06-08 15:42:05 UTC
When I create two new folders, and try to move first into second, dolphin crashes. reverting http://quickgit.kde.org/index.php?p=kdelibs.git&a=commit&h=a43824a200ed76cef48a90bd3aee8547698b7c91 fixes it for me Raising severity, as it affects multiple applications and default setting is "nepomuk enabled". There is definitely something weird going on. If i add Q_ASSERT(!m_factories.hasLocalData()); to the KSycocaFactorySingleton constructor it asserts when nepomukserver is running but works correctly when nepomukserver is not running. Something is writing way off memory maybe? Couldn't find anything usefuf with valgrind The error in my system happens when I try to start kmail. It always crashes. Just after that, if I click on nepomuk notification icon it also crashes. Here is the bare output: $ kmail QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. kmail2(1435)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: kmail2(1435)/kdepimlibs (mailtransport): Could not access Outbox. kmail2(1435)/kdeui (kdelibs): Attempt to use QAction "" with KXMLGUIFactory! QObject: Cannot create children for a parent that is in a different thread. (Parent is Nepomuk::ResourceManager(0x207f6e0), parent's thread is QThread(0x1be8260), current thread is QThread(0x21df420) *** KMail got signal 11 (Exiting) *** Dead letters dumped. This bug, in fact, is so severe that it would merit a 4.8.4.1 release. The following apps are affected. - Gwenview: Instant crash while trying to open a folder. - Dolphin: If you open the Information panel when Nepomuk is enabled, nothing appears. If you enabled Dolphin tooltips, Dolphin will crash. - KMail: It will crash instantly when you try to Reply To a mail. - Even Danbooru Client crashes while trying to save images (this is to certify that this is a Nepomuk bug). This affects ONLY KDE 4.8.4. This doesn't affect KDE 4.8.3. Also, KDE 4.8.80 doesn't seem to be affected either. This dolphin bug was reported yesterday: https://bugs.kde.org/show_bug.cgi?id=301499 It's marked as a Duplicate, the original bug is quite old, and it was caused by an old soprano-version. As the backtraces look quite similar, I thought that soprano could be the cause here, too. I am running latest stable (2.7.6), and get those crashes, too. So I upgraded to 2.7.56 (alpha? beta? don't know...) - and all crashes are gone! Everything just works! Confirmed. Upgrading to soprano 2.7.56 on KDE 4.8.4 fixed the crash! There are no crashes here! But please, leave this open; we shouldn't depend on Soprano trunk if we are in the stable branch; if we do that, releases and branching don't make any sense. Yes, asking for a soprano increase from 4.8.3 to 4.8.4 is unacceptable. I can confirm soprano-2.7.57 on 4.8.4 fixes the crash problems mentioned in this report on my Fedora17 box. There seems to be a discrepancy between the patch applied to nepomuk in the git and the kdelibs 4.8.4 source. I see the extra line below if ( forced || (!m_socketConnectFailed && !localSocketClient.isConnected()) ) { delete localSocketModel; localSocketModel = 0; localSocketClient.disconnect(); <======== THIS LINE IS EXTRA QString socketName = KGlobal::dirs()->locateLocal( "socket", "nepomuk-socket" ); If I remove that the crashes stop as well. The git patch that changed the first line above does not have that line in the patch! (In reply to comment #11) > I can confirm soprano-2.7.57 on 4.8.4 fixes the crash problems mentioned in > this report on my Fedora17 box. Me too. (In reply to comment #12) > There seems to be a discrepancy between the patch applied to nepomuk in > the git and the kdelibs 4.8.4 source. > > I see the extra line below > localSocketClient.disconnect(); <======== THIS LINE IS EXTRA > If I remove that the crashes stop as well. The git patch that changed the > first line above does not have that line in the patch! That's just a workaround. Soprano::LocalSocketClient::disconnect() did not change between soprano-2.7.6 and latest betas. IMHO disconnect() is needed, because otherwise you will get an error in the case force is true. LocalSocketClient::connect() checks if there is a connection, yet, and if it won't reconnect but set an error (for both stable and beta soprano). The problems we are facing here are - as so often in the past - Qt Sockets. Trueg complained about it in the past and after 2.7.6 finally fixed it with the new Soprano::Socket-class. I extracted a pach from the diff between stable and beta, that simply replaces Qt Sockets with Soprano::Socket and installed 2.7.6 with it. It runs stable since about a day. Up. Can you fix this (or confirm that reverting a43824a200ed76cef48a90bd3aee8547698b7c91 is ok) so people can use Nepomuk again? Reverted the following commits in KDE/4.8.x branch - commit 3708be2d09700b21f934c2129218e1c7ea44efdf Author: Sebastian Trueg <trueg@kde.org> Date: Mon Apr 30 16:34:21 2012 +0200 Disconnect before re-connecting. Soprano does not do that for us. commit a43824a200ed76cef48a90bd3aee8547698b7c91 Author: Sebastian Trueg <trueg@kde.org> Date: Mon Apr 30 14:51:10 2012 +0200 Always rec-connect if forced (ie. when Nepomuk server restarts) This should fix the issue. *** Bug 302039 has been marked as a duplicate of this bug. *** *** Bug 301790 has been marked as a duplicate of this bug. *** *** Bug 301474 has been marked as a duplicate of this bug. *** *** Bug 301685 has been marked as a duplicate of this bug. *** |