Application: kopete (1.7.3) KDE Platform Version: 4.14.14 Qt Version: 4.8.7 Operating System: Linux 4.2.5-1-ARCH x86_64 Distribution: "Arch Linux" -- Information about the crash: - What I was doing when the application crashed: Started Kopete, opened a new Window (Chat, settings), closed it again. Kopete crashes immediately. -- Backtrace: Application: Kopete (kopete), signal: Segmentation fault Using host libthread_db library "/usr/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7f04ff067800 (LWP 8170))] Thread 3 (Thread 0x7f04e1f51700 (LWP 8171)): #0 0x00007f04f64d85f9 in g_mutex_lock () from /usr/lib/libglib-2.0.so.0 #1 0x00007f04f6493559 in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0 #2 0x00007f04f6493eeb in ?? () from /usr/lib/libglib-2.0.so.0 #3 0x00007f04f64940cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #4 0x00007f04fcac1886 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #5 0x00007f04fca8fde1 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #6 0x00007f04fca90155 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #7 0x00007f04e491d5d3 in QCA::SyncThread::run() () from /usr/lib/libqca.so.2 #8 0x00007f04fc98113c in ?? () from /usr/lib/libQtCore.so.4 #9 0x00007f04f842e4a4 in start_thread () from /usr/lib/libpthread.so.0 #10 0x00007f04fb2f913d in clone () from /usr/lib/libc.so.6 Thread 2 (Thread 0x7f04e1750700 (LWP 8172)): #0 0x00007f04fb2f018d in poll () from /usr/lib/libc.so.6 #1 0x00007f04f6493fbc in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007f04f64940cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007f04fcac1886 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #4 0x00007f04fca8fde1 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #5 0x00007f04fca90155 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #6 0x00007f04fc97e849 in QThread::exec() () from /usr/lib/libQtCore.so.4 #7 0x00007f04e4d610ba in ?? () from /usr/lib/kde4/kopete_jabber.so #8 0x00007f04fc98113c in ?? () from /usr/lib/libQtCore.so.4 #9 0x00007f04f842e4a4 in start_thread () from /usr/lib/libpthread.so.0 #10 0x00007f04fb2f913d in clone () from /usr/lib/libc.so.6 Thread 1 (Thread 0x7f04ff067800 (LWP 8170)): [KCrash Handler] #6 0x00007f04fb5aef58 in main_arena () from /usr/lib/libc.so.6 #7 0x00007f04fcaa6aa5 in QObject::disconnect(QObject const*, char const*, QObject const*, char const*) () from /usr/lib/libQtCore.so.4 #8 0x00007f04f52204a9 in KParts::PartManager::~PartManager() () from /usr/lib/libkparts.so.4 #9 0x00007f04f5220679 in KParts::PartManager::~PartManager() () from /usr/lib/libkparts.so.4 #10 0x00007f04fcaa98e1 in QObjectPrivate::deleteChildren() () from /usr/lib/libQtCore.so.4 #11 0x00007f04fcaabf84 in QObject::~QObject() () from /usr/lib/libQtCore.so.4 #12 0x00007f04f5219f7e in KParts::Part::~Part() () from /usr/lib/libkparts.so.4 #13 0x00007f04e5ddda6d in KHTMLPart::~KHTMLPart() () from /usr/lib/libkhtml.so.5 #14 0x00007f04e65ebd27 in ChatMessagePart::~ChatMessagePart() () from /usr/lib/libkopetechatwindow_shared.so.1 #15 0x00007f04e65ebe79 in ChatMessagePart::~ChatMessagePart() () from /usr/lib/libkopetechatwindow_shared.so.1 #16 0x00007f04fcaab408 in QObject::event(QEvent*) () from /usr/lib/libQtCore.so.4 #17 0x00007f04fbb3839c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #18 0x00007f04fbb3f1f6 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #19 0x00007f04fd54485a in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5 #20 0x00007f04fca9156d in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4 #21 0x00007f04fca949f6 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQtCore.so.4 #22 0x00007f04fcac1713 in ?? () from /usr/lib/libQtCore.so.4 #23 0x00007f04f6493dc7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #24 0x00007f04f6494020 in ?? () from /usr/lib/libglib-2.0.so.0 #25 0x00007f04f64940cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #26 0x00007f04fcac1864 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #27 0x00007f04fbbe13b6 in ?? () from /usr/lib/libQtGui.so.4 #28 0x00007f04fca8fde1 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #29 0x00007f04fca90155 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #30 0x00007f04fca95b09 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #31 0x0000000000414175 in ?? () #32 0x00007f04fb230610 in __libc_start_main () from /usr/lib/libc.so.6 #33 0x0000000000414959 in _start () Reported using DrKonqi
Probably useful: I run Kopete in a Plasma 5 environment. Kopete has not been migrated to kf5 and Qt5 on archlinux yet.
Created attachment 95500 [details] New crash information added by DrKonqi kopete (1.7.3) on KDE Platform 4.14.14 using Qt 4.8.7 - What I was doing when the application crashed: Kopete has been running for several hours. Several chat windows were open. Kopete crashed when closing a window of a chat via an ICQ account with someone whose status was invisible and who sent me one single message to which I had not replied. -- Backtrace (Reduced): #7 0x00007f16350ca595 in QObject::disconnect (sender=0x2cfe6a0, signal=0x2d35e29 "destroyed()", signal@entry=0x7f162d8cd500 "2destroyed()", receiver=receiver@entry=0x2d3c530, method=0x2d3c789 "slotManagedTopLevelWidgetDestroyed()", method@entry=0x7f162d8ce218 "1slotManagedTopLevelWidgetDestroyed()") at /var/tmp/portage/dev-qt/qtcore-4.8.7-r1/work/qt-everywhere-opensource-src-4.8.7/src/corelib/kernel/qobject.cpp:2911 #8 0x00007f162d8b4936 in KParts::PartManager::~PartManager (this=0x2d3c530, __in_chrg=<optimized out>) at /var/tmp/portage/kde-base/kdelibs-4.14.14/work/kdelibs-4.14.14/kparts/partmanager.cpp:132 #9 0x00007f162d8b4a67 in KParts::PartManager::~PartManager (this=0x2d3c530, __in_chrg=<optimized out>) at /var/tmp/portage/kde-base/kdelibs-4.14.14/work/kdelibs-4.14.14/kparts/partmanager.cpp:143 #10 0x00007f16350c8540 in QObjectPrivate::deleteChildren (this=this@entry=0xfce8b0) at /var/tmp/portage/dev-qt/qtcore-4.8.7-r1/work/qt-everywhere-opensource-src-4.8.7/src/corelib/kernel/qobject.cpp:1935 #11 0x00007f16350ce490 in QObject::~QObject (this=0x2ce9670, __in_chrg=<optimized out>) at /var/tmp/portage/dev-qt/qtcore-4.8.7-r1/work/qt-everywhere-opensource-src-4.8.7/src/corelib/kernel/qobject.cpp:954
Happens now always with 1. starting kopete 2. setting status to online 3. opening a chat window 4. closing the just opened chat window My first guess is that this came with the update to Applications 15.08.3. In that case, there will be duplicates incoming.
Looks like the change that lead to making kopete crash now is not located in kopete, but in kdelibs. Kopete does not crash with kdelibs 4.14.13, but it *does* crash with kdelibs 4.14.14. I suppose it is commit 4f7ea2f77... (not verified): > backport commit b72fc5e56579035bf987075e16324ef95ef8e3d4 > Use deleteLater in Part::slotWidgetDestroyed(). Adding Allen Winter and Alex Marry to CC: Maybe you can easily spot what is going wrong here?
*** Bug 355377 has been marked as a duplicate of this bug. ***
That commit is supposed to *prevent* crashes like this, but it changes the destructor order, so it could well be promoting an existing bug to a crash. Looking at the backtrace, for some reason the PartManager for KHTML is not removing one of its managed widgets when it's destroyed. My guess is that in void PartManager::removeManagedTopLevelWidget(const QWidget *topLevel) { if (!topLevel->isTopLevel()) { return; } d->m_managedTopLevelWidgets.removeAll(topLevel); } isTopLevel() is not true when the widget is destroyed, even though it was when it was added. But that's just a guess. I'll need to make a build of kdelibs4 to check.
This also happens when closing the Settings windows and not only a chat window.
Kopete Version 1.7.3 KDE 4.14.14 running on arch linux i get the same crash every time when closing settings or any chat window in kopete.
Created attachment 95563 [details] New crash information added by DrKonqi kopete (1.6.60) on KDE Platform 4.14.14 using Qt 4.8.7 - What I was doing when the application crashed: Open Kopete -> open random subwindow -> close it -> Kopete crashes -- Backtrace (Reduced): #7 0x00007fbdd5eafee5 in QObject::disconnect (sender=0x564be9c92720, signal=0x564be9f66d99 "destroyed()", signal@entry=0x7fbdd8562f07 "2destroyed()", receiver=receiver@entry=0x564be9f6ee00, method=0x564be9f6a059 "slotManagedTopLevelWidgetDestroyed()", method@entry=0x7fbdd8563b38 "1slotManagedTopLevelWidgetDestroyed()") at kernel/qobject.cpp:2911 #8 0x00007fbdd8548f09 in KParts::PartManager::~PartManager (this=0x564be9f6ee00, __in_chrg=<optimized out>) at ../../kparts/partmanager.cpp:132 #9 0x00007fbdd85490d9 in KParts::PartManager::~PartManager (this=0x564be9f6ee00, __in_chrg=<optimized out>) at ../../kparts/partmanager.cpp:143 #10 0x00007fbdd5eb2d21 in QObjectPrivate::deleteChildren (this=this@entry=0x564be9e15860) at kernel/qobject.cpp:1935 #11 0x00007fbdd5eb53c4 in QObject::~QObject (this=0x564be9ebace0, __in_chrg=<optimized out>) at kernel/qobject.cpp:954
*** Bug 355511 has been marked as a duplicate of this bug. ***
*** Bug 355510 has been marked as a duplicate of this bug. ***
*** Bug 355597 has been marked as a duplicate of this bug. ***
*** Bug 355610 has been marked as a duplicate of this bug. ***
Created attachment 95619 [details] New crash information added by DrKonqi kopete (1.6.60) on KDE Platform 4.14.14 using Qt 4.8.7 - What I was doing when the application crashed: Closed main window while a chat window was open. Then closed chat window. -- Backtrace (Reduced): #7 0x00007f16862d6ee5 in QObject::disconnect (sender=0x5646f4bcbb30, signal=0x5646f4c7d8d9 "destroyed()", signal@entry=0x7f1688989f07 "2destroyed()", receiver=receiver@entry=0x5646f45b7bf0, method=0x5646f4d93fe9 "slotManagedTopLevelWidgetDestroyed()", method@entry=0x7f168898ab38 "1slotManagedTopLevelWidgetDestroyed()") at kernel/qobject.cpp:2911 #8 0x00007f168896ff09 in KParts::PartManager::~PartManager (this=0x5646f45b7bf0, __in_chrg=<optimized out>) at ../../kparts/partmanager.cpp:132 #9 0x00007f16889700d9 in KParts::PartManager::~PartManager (this=0x5646f45b7bf0, __in_chrg=<optimized out>) at ../../kparts/partmanager.cpp:143 #10 0x00007f16862d9d21 in QObjectPrivate::deleteChildren (this=this@entry=0x5646f4a1a190) at kernel/qobject.cpp:1935 #11 0x00007f16862dc3c4 in QObject::~QObject (this=0x5646f4b94630, __in_chrg=<optimized out>) at kernel/qobject.cpp:954
*** Bug 355653 has been marked as a duplicate of this bug. ***
Created attachment 95640 [details] New crash information added by DrKonqi kopete (1.7.3) on KDE Platform 4.14.14 using Qt 4.8.7 reproduce: 1) open a chat window 2) close the chat window problem also occurs with the ctrl+F4 combination -- Backtrace (Reduced): #7 0x00007f3f4b3cbaa5 in QObject::disconnect(QObject const*, char const*, QObject const*, char const*) () from /usr/lib/libQtCore.so.4 #8 0x00007f3f43b544a9 in KParts::PartManager::~PartManager() () from /usr/lib/libkparts.so.4 #9 0x00007f3f43b54679 in KParts::PartManager::~PartManager() () from /usr/lib/libkparts.so.4 #10 0x00007f3f4b3ce8e1 in QObjectPrivate::deleteChildren() () from /usr/lib/libQtCore.so.4 #11 0x00007f3f4b3d0f84 in QObject::~QObject() () from /usr/lib/libQtCore.so.4
When I try to reproduce this, I get a different crash, apparently because ChatSessionPart is trying to run changeStyle() after the KHTMLPart's widget has been destroyed (but before the Part itself has been destroyed, I guess). This causes a crash when KHTMLPart::begin() is called from writeTemplate(), and even if I fix that by neutering begin() when the widget was destroyed, adjustStyleVariantForChatSession() still tries to access the now-deleted manager variable (which was deleted when KCModuleProxy::deleteClient() deleted Kopete::Account). All of which is to say that the change introduced by https://quickgit.kde.org/?p=kdelibs.git&a=commit&h=4f7ea2f770cf062ef22293fbb21a086f3e0cbfcb might cause as many crashes as it cures, since Kopete at least seems to have deep-seated assumptions about the destruction sequence.
*** Bug 356002 has been marked as a duplicate of this bug. ***
*** Bug 356130 has been marked as a duplicate of this bug. ***
You are right, switching back to kdelibs-4.14.13 solves the problem so far.
*** Bug 356164 has been marked as a duplicate of this bug. ***
Moving to kdelibs product and chaning priority as this is very critical. Now we know that Kopete start crashing after upgrading kdelibs, so this is kdelibs problem. @Alex Merry: Do you have idea how to fix it?
What makes this "very critical"? is there harm or data loss?
Ah, nevermind, it's even about closing chat windows, not necessarily about closing the application
Well, a quick fix would be to revert commit 4f7ea2f77. That would stop Kopete crashing, at the expense of making Akregator crash randomly again. The proper fix is to track down the destructor order dependencies and do things like use QPointers to refer to objects that aren't your children, and test for them being unset before accessing them. KParts just ends up making destruction complicated, because the main widget is kind of owned by two things - the widget it's embedded in and the Part itself.
Was the commit in kdelibs also ported to KF5Parts framework? See bug 355711.
(In reply to Martin Walch from comment #4) > Looks like the change that lead to making kopete crash now is not located in > kopete, but in kdelibs. > > Kopete does not crash with kdelibs 4.14.13, but it *does* crash with kdelibs > 4.14.14. Until a fix is in place can users build a standalone kopete version statically linked against kdelibs 4.14.13? I can see the advantages of Telepathy but until it gets to be as feature rich as Kopete this could make users lives easier providing that they are willing to go an extra mile and compile themselves. If that's possible can you provide the steps or a reference on how we go about it? Apologies if I should have asked this elsewhere. And thanks for keeping Kopete alive :)
It was a commit I originally made in KF5Parts, and was backported to kdelibs. It seems like it's one of those changes that is "damned if you do, damned if you don't" - I still think the change was correct (in that I suspect it's not possible to avoid certain crash-at-exit/crash-on-close scenarios without it), but there's more code around than I thought that depends on the old behaviour.
Created attachment 95943 [details] New crash information added by DrKonqi kopete (1.7.3) on KDE Platform 4.14.14 using Qt 4.8.7 - What I was doing when the application crashed: Enter the settings > configure > behavior > chat and then clicked on "OK" Button to close that window -- Backtrace (Reduced): #6 0x00007fe997ad1f39 in KHTMLPart::begin(KUrl const&, int, int) () from /usr/lib/libkhtml.so.5 #7 0x00007fe9982d6541 in ChatMessagePart::writeTemplate() () from /usr/lib/libkopetechatwindow_shared.so.1 #8 0x00007fe9982ddb00 in ChatMessagePart::changeStyle() () from /usr/lib/libkopetechatwindow_shared.so.1 #9 0x00007fe9ad5b33e1 in QObject::event(QEvent*) () from /usr/lib/libQtCore.so.4 #10 0x00007fe9ac63739c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
*** Bug 356420 has been marked as a duplicate of this bug. ***
*** Bug 356396 has been marked as a duplicate of this bug. ***
Created attachment 96082 [details] New crash information added by DrKonqi kopete (1.7.3) on KDE Platform 4.14.14 using Qt 4.8.7 - What I was doing when the application crashed: I was closing the conversation window. It happens everytime I do it -- Backtrace (Reduced): #7 0x00007f62f2c80a75 in QObject::disconnect(QObject const*, char const*, QObject const*, char const*) () from /usr/lib/libQtCore.so.4 #8 0x00007f62eb4254a9 in KParts::PartManager::~PartManager() () from /usr/lib/libkparts.so.4 #9 0x00007f62eb425679 in KParts::PartManager::~PartManager() () from /usr/lib/libkparts.so.4 #10 0x00007f62f2c838b1 in QObjectPrivate::deleteChildren() () from /usr/lib/libQtCore.so.4 #11 0x00007f62f2c85f54 in QObject::~QObject() () from /usr/lib/libQtCore.so.4
Alex, change was not obviously correct because it totally broke Kopete. And from my side such commit should be reverted as ASAP because it broke existing SW which use it. Non-working Kopete with new kdelibs (which is not breaking API/ABI) is a big problem. It new version of kdelibs is ABI incompatible with old one, it should increase soversion in library.
The change discussed here does not affect API/ABI
From Kopete point of view, this was something like API change. As it does not work with new kdelibs. We can name it different (not API change) if you do not want, but it is something which prevent upgrading kdelibs to new version when Kopete is installed.
Right, I'm going to revert in kdelibs, because this is clearly causing more issues than it solves. I'm going to leave the change in Frameworks for now, though, where the benefits seem to be outweighing the problems from what I've seen.
Git commit a02df05e4bd083f98147c86f88da2f818fc6c9f4 by Alex Merry. Committed on 15/12/2015 at 19:26. Pushed by alexmerry into branch 'KDE/4.14'. Revert "backport commit b72fc5e56579035bf987075e16324ef95ef8e3d4" This reverts commit 4f7ea2f770cf062ef22293fbb21a086f3e0cbfcb. This change seems to be causing more problems than it fixes - it's probably just too big of a behaviour change for kdelibs. Which means that akregator will probably keep randomly crashing, but the alternative seems to be various other applications consistently crashing at exit. If we can fix those applications (Kopete in particular), we can consider re-applying this afterwards. M +1 -1 kparts/part.cpp M +0 -2 kparts/tests/parttest.cpp http://commits.kde.org/kdelibs/a02df05e4bd083f98147c86f88da2f818fc6c9f4
Ok, Alex do you have idea how to fix this problem in Kopete? Kopete is on its way in porting to KF5 and so KF5 Kopete version must be fixed...
*** Bug 356734 has been marked as a duplicate of this bug. ***
Created attachment 96122 [details] New crash information added by DrKonqi kopete (1.7.3) on KDE Platform 4.14.14 using Qt 4.8.7 - What I was doing when the application crashed: I've been closing a chat window. It seems that app crashes after closing any window. -- Backtrace (Reduced): #7 0x00007f8802e46a75 in QObject::disconnect(QObject const*, char const*, QObject const*, char const*) () from /usr/lib/libQtCore.so.4 #8 0x00007f87fb5eb4a9 in KParts::PartManager::~PartManager() () from /usr/lib/libkparts.so.4 #9 0x00007f87fb5eb679 in KParts::PartManager::~PartManager() () from /usr/lib/libkparts.so.4 #10 0x00007f8802e498b1 in QObjectPrivate::deleteChildren() () from /usr/lib/libQtCore.so.4 #11 0x00007f8802e4bf54 in QObject::~QObject() () from /usr/lib/libQtCore.so.4
Basically, you need to be a bit more flexible about destructor order. KParts can be destroyed starting with the Part itself *or* starting with the central widget. The old behaviour was that if the widget was destroyed first, the Part would be deleted at some point during the widget's destructor (actually in the QObject destructor, when the destroyed() signal is emitted). This meant that, for example, the main widget object still (mostly) existed when your KPart was destroyed. You could get away with doing things to it (most of the time - it's undefined behaviour, really, but it generally worked). The new behaviour is that when the widget is destroyed, it is destroyed completely, *then* control returns to the event loop, *then* the Part is deleted. So you need to code your Part with the assumption that the central widget might disappear on you at any point. Note that the core problem (ambiguous destructor order) hasn't changed. The old code allowed you to get away with things you shouldn't be doing, while the new code allows you to code defensively using QPointers and the like. You might want to try running under valgrind (with kdelibs 4.14.14 or with KF5) to find where your assumptions about destruction ordering don't hold.
For me this problem is not fixed. Kopete still crashes every time when I close chat window. I have latest kdelibs version (4.14.15-1) Distro: Arch Linux KF5 Version: 5.17.0 Plasma version: 5.5.1 KDE Aplications version: 15.12.0 Crash: Application: Kopete (kopete), signal: Segmentation fault Using host libthread_db library "/usr/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7fe2f4e9f840 (LWP 4252))] Thread 3 (Thread 0x7fe2d3950700 (LWP 4273)): #0 0x00007fe2f111118d in poll () from /usr/lib/libc.so.6 #1 0x00007fe2ec2d1fbc in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007fe2ec2d20cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007fe2f28e2856 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #4 0x00007fe2f28b0dc1 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #5 0x00007fe2f28b1135 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #6 0x00007fe2dad22053 in QCA::SyncThread::run() () from /usr/lib/libqca.so.2 #7 0x00007fe2f27a214c in ?? () from /usr/lib/libQtCore.so.4 #8 0x00007fe2ee2494a4 in start_thread () from /usr/lib/libpthread.so.0 #9 0x00007fe2f111a13d in clone () from /usr/lib/libc.so.6 Thread 2 (Thread 0x7fe2d314f700 (LWP 4274)): #0 0x00007fe2f111118d in poll () from /usr/lib/libc.so.6 #1 0x00007fe2ec2d1fbc in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007fe2ec2d20cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007fe2f28e2856 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #4 0x00007fe2f28b0dc1 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #5 0x00007fe2f28b1135 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #6 0x00007fe2f279f859 in QThread::exec() () from /usr/lib/libQtCore.so.4 #7 0x00007fe2db16413a in ?? () from /usr/lib/kde4/kopete_jabber.so #8 0x00007fe2f27a214c in ?? () from /usr/lib/libQtCore.so.4 #9 0x00007fe2ee2494a4 in start_thread () from /usr/lib/libpthread.so.0 #10 0x00007fe2f111a13d in clone () from /usr/lib/libc.so.6 Thread 1 (Thread 0x7fe2f4e9f840 (LWP 4252)): [KCrash Handler] #6 0x0000000000000000 in ?? () #7 0x00007fe2f28c7a75 in QObject::disconnect(QObject const*, char const*, QObject const*, char const*) () from /usr/lib/libQtCore.so.4 #8 0x00007fe2eb06c4a9 in KParts::PartManager::~PartManager() () from /usr/lib/libkparts.so.4 #9 0x00007fe2eb06c679 in KParts::PartManager::~PartManager() () from /usr/lib/libkparts.so.4 #10 0x00007fe2f28ca8b1 in QObjectPrivate::deleteChildren() () from /usr/lib/libQtCore.so.4 #11 0x00007fe2f28ccf54 in QObject::~QObject() () from /usr/lib/libQtCore.so.4 #12 0x00007fe2eb065f7e in KParts::Part::~Part() () from /usr/lib/libkparts.so.4 #13 0x00007fe2dc802a6d in KHTMLPart::~KHTMLPart() () from /usr/lib/libkhtml.so.5 #14 0x00007fe2dd011d27 in ChatMessagePart::~ChatMessagePart() () from /usr/lib/libkopetechatwindow_shared.so.1 #15 0x00007fe2dd011e79 in ChatMessagePart::~ChatMessagePart() () from /usr/lib/libkopetechatwindow_shared.so.1 #16 0x00007fe2f28cc3d8 in QObject::event(QEvent*) () from /usr/lib/libQtCore.so.4 #17 0x00007fe2f195939c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #18 0x00007fe2f19601f6 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #19 0x00007fe2f33658aa in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5 #20 0x00007fe2f28b254d in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4 #21 0x00007fe2f28b59d6 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQtCore.so.4 #22 0x00007fe2f28e26e3 in ?? () from /usr/lib/libQtCore.so.4 #23 0x00007fe2ec2d1dc7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #24 0x00007fe2ec2d2020 in ?? () from /usr/lib/libglib-2.0.so.0 #25 0x00007fe2ec2d20cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #26 0x00007fe2f28e2834 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #27 0x00007fe2f1a023f6 in ?? () from /usr/lib/libQtGui.so.4 #28 0x00007fe2f28b0dc1 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #29 0x00007fe2f28b1135 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #30 0x00007fe2f28b6ad9 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #31 0x0000000000414175 in ?? () #32 0x00007fe2f1051610 in __libc_start_main () from /usr/lib/libc.so.6 #33 0x0000000000414959 in _start ()
fyi, Fixed In: 4.14.15 is wrong, this commit came after 4.14.15 tagging/release as far as I can tell, adjusting to 4.14.16
I committed it before the 4.14.15 tag had been pushed, so I assumed I'd made it, but clearly not.
Hi, I use Arch Linux. Problem still exists!!!! Kopete version: 1.8.0 Frameworks: 5.17 Plasma: 5.5.2 Application: 15.12 kdelibs 4.14.15-1 Not fixed! p.
(In reply to szymon.pysz@gmail.com from comment #45) > kdelibs 4.14.15-1 > > Not fixed! See description - it will be fixed in 4.14.16.
Created attachment 96523 [details] New crash information added by DrKonqi kopete (1.7.3) on KDE Platform 4.14.14 using Qt 4.8.6 - What I was doing when the application crashed: I was playing with settings in Kopete and I closed a chat window and it crashed. -- Backtrace (Reduced): #7 0x00007f82929c43c5 in QObject::disconnect (sender=0x3177df0, signal=0x3394e19 "destroyed()", signal@entry=0x7f828af92293 "2destroyed()", receiver=receiver@entry=0x307c4e0, method=0x339b349 "slotManagedTopLevelWidgetDestroyed()", method@entry=0x7f828af92eb8 "1slotManagedTopLevelWidgetDestroyed()") at kernel/qobject.cpp:2911 #8 0x00007f828af780d9 in KParts::PartManager::~PartManager (this=0x307c4e0, __in_chrg=<optimized out>) at ../../kparts/partmanager.cpp:132 #9 0x00007f828af782a9 in KParts::PartManager::~PartManager (this=0x307c4e0, __in_chrg=<optimized out>) at ../../kparts/partmanager.cpp:143 #10 0x00007f82929c7201 in QObjectPrivate::deleteChildren (this=this@entry=0x313e260) at kernel/qobject.cpp:1935 #11 0x00007f82929c98a4 in QObject::~QObject (this=0x312eb50, __in_chrg=<optimized out>) at kernel/qobject.cpp:954
Created attachment 97714 [details] New crash information added by DrKonqi kopete (1.7.3) on KDE Platform 4.14.14 using Qt 4.8.7 - What I was doing when the application crashed: Kopete crashes whenever I close a chat window. I only use a jabber account. It cccurs with jabber and gmail users, using OTR or not. -- Backtrace (Reduced): #7 0x00007f7a68f27525 in QObject::disconnect(QObject const*, char const*, QObject const*, char const*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #8 0x00007f7a612b4e09 in KParts::PartManager::~PartManager() () from /usr/lib/libkparts.so.4 #9 0x00007f7a612b4fd9 in KParts::PartManager::~PartManager() () from /usr/lib/libkparts.so.4 #10 0x00007f7a68f2a361 in QObjectPrivate::deleteChildren() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #11 0x00007f7a68f2ca04 in QObject::~QObject() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
@mando: See that it is fixed in KDE version 4.14.16, but you have only 4.14.14.
*** Bug 358922 has been marked as a duplicate of this bug. ***
Sorry for being too late, I faced this issue while porting Kopete to KF5 and fixed it with some minor commit: https://quickgit.kde.org/?p=kopete.git&a=commit&h=0f259ada3a4646b0230d6870ff185adfcb3b1085. To my investigation on this crash, it seems to be not due to the deletion order itself, but because of reparenting KHTML's view() subpart from previous parent specified in ctor call to QSplitter which leads to double deletion of the widget. I didn't dig into details, but in my toy application with KParts this is not preproducible without KHTML. Given that specifying parent for widget which gets reparented in a couple of lines doesn't change things too seriously, I just removed this specification. In general, it seems that there's some issue with parent changing and double deletion. @Alex Merry probably have more details on this, maybe he has some ideas about the actual cause according to this.
*** Bug 363709 has been marked as a duplicate of this bug. ***