Bug 204399

looking at the backtrace its either a broken Qt build or a bug in Qt. Apart from that no clear reproduction steps.

*** Bug 205206 has been marked as a duplicate of this bug. ***

*** Bug 209935 has been marked as a duplicate of this bug. ***

*** Bug 220427 has been marked as a duplicate of this bug. ***

*** Bug 226067 has been marked as a duplicate of this bug. ***

*** Bug 243803 has been marked as a duplicate of this bug. ***

*** Bug 212949 has been marked as a duplicate of this bug. ***

we have to do something about this one, quite a few duplicate reports.

Better backtrace from bug 243803:
Application: kdevelop (4.0.0 (using KDevPlatform 1.0.0))
KDE Platform Version: 4.4.2 (KDE 4.4.2)
Qt Version: 4.6.2
Operating System: Linux 2.6.32-23-generic-pae i686
Distribution: Ubuntu 10.04 LTS

Thread 1 (Thread 0xb478f710 (LWP 19570)):
[KCrash Handler]
#6  0xb6b3dc15 in QAbstractItemView::sizeHintForRow (this=0x9ad23f8, row=0) at
itemviews/qabstractitemview.cpp:2905
#7  0xb6b805e3 in QTreeView::scrollContentsBy (this=0x9ad23f8, dx=0, dy=1) at
itemviews/qtreeview.cpp:2349
#8  0xb6a89d65 in QAbstractScrollAreaPrivate::_q_vslide (this=0x9ad8ea0, y=1)
at widgets/qabstractscrollarea.cpp:1310
#9  0xb6a8b3d2 in QAbstractScrollArea::qt_metacall (this=0x9ad23f8,
_c=QMetaObject::InvokeMetaMethod, _id=2, _a=0xbf953f18) at
.moc/release-shared/moc_qabstractscrollarea.cpp:85
#10 0xb6b3948a in QAbstractItemView::qt_metacall (this=0x9ad23f8,
_c=QMetaObject::InvokeMetaMethod, _id=29, _a=0xbf953f18) at
.moc/release-shared/moc_qabstractitemview.cpp:213
#11 0xb6b8798a in QTreeView::qt_metacall (this=0x9ad23f8,
_c=QMetaObject::InvokeMetaMethod, _id=29, _a=0xbf953f18) at
.moc/release-shared/moc_qtreeview.cpp:119
#12 0xb522ba5a in KDevelop::FocusedTreeView::qt_metacall (this=0x9ad23f8,
_c=QMetaObject::InvokeMetaMethod, _id=29, _a=0xbf953f18) at
./focusedtreeview.moc:68
#13 0xb7049c9a in QMetaObject::metacall (object=0x9ad23f8, cl=3214228564,
idx=29, argv=0xbf953f18) at kernel/qmetaobject.cpp:237
#14 0xb70583d5 in QMetaObject::activate (sender=0x9ad9d50, m=0xb6ed09f4,
local_signal_index=0, argv=0xbf953f18) at kernel/qobject.cpp:3293
#15 0xb6cc0be3 in QAbstractSlider::valueChanged (this=0x9ad9d50, _t1=1) at
.moc/release-shared/moc_qabstractslider.cpp:182
#16 0xb69a30e7 in QAbstractSlider::setValue (this=0x9ad9d50, value=1) at
widgets/qabstractslider.cpp:542
#17 0xb69a3acc in QAbstractSlider::setRange (this=0x9ad9d50, min=0, max=1) at
widgets/qabstractslider.cpp:251
#18 0xb6b7a5a0 in QTreeViewPrivate::updateScrollBars (this=0x9ad8ea0) at
itemviews/qtreeview.cpp:3492
#19 0xb6b7aaa5 in QTreeView::updateGeometries (this=0x9ad23f8) at
itemviews/qtreeview.cpp:2745
#20 0xb6b2fd64 in QAbstractItemView::resizeEvent (this=0x9ad23f8,
event=0xbf954918) at itemviews/qabstractitemview.cpp:2338
#21 0xb65f3643 in QWidget::event (this=0x9ad23f8, event=0xbf954918) at
kernel/qwidget.cpp:8152
#22 0xb69effd3 in QFrame::event (this=0x9ad23f8, e=0xbf954918) at
widgets/qframe.cpp:557
#23 0xb6a8a382 in QAbstractScrollArea::viewportEvent (this=0xbf953c54,
e=0xbf953bb8) at widgets/qabstractscrollarea.cpp:1036
#24 0xb6b3ebd7 in QAbstractItemView::viewportEvent (this=0x9ad23f8,
event=0xbf954918) at itemviews/qabstractitemview.cpp:1610
#25 0xb6b7ff7c in QTreeView::viewportEvent (this=0x9ad23f8, event=0xbf954918)
at itemviews/qtreeview.cpp:1248
#26 0xb6a8cc65 in QAbstractScrollAreaPrivate::viewportEvent (this=0x9ada2a0,
o=0x9ad4658, e=0xbf954918) at widgets/qabstractscrollarea_p.h:100
#27 QAbstractScrollAreaFilter::eventFilter (this=0x9ada2a0, o=0x9ad4658,
e=0xbf954918) at widgets/qabstractscrollarea_p.h:116
#28 0xb7043cda in QCoreApplicationPrivate::sendThroughObjectEventFilters
(this=0x847c558, receiver=0x9ad4658, event=0xbf954918) at
kernel/qcoreapplication.cpp:819
#29 0xb65954b9 in QApplicationPrivate::notify_helper (this=0x847c558,
receiver=0x9ad4658, e=0xbf954918) at kernel/qapplication.cpp:4296
#30 0xb659c0f9 in QApplication::notify (this=0xbf955958, receiver=0x9ad4658,
e=0xbf954918) at kernel/qapplication.cpp:4265
#31 0xb7339f2a in KApplication::notify (this=0xbf955958, receiver=0x9ad4658,
event=0xbf954918) at ../../kdeui/kernel/kapplication.cpp:302
#32 0xb7044a3b in QCoreApplication::notifyInternal (this=0xbf955958,
receiver=0x9ad4658, event=0xbf954918) at kernel/qcoreapplication.cpp:704
#33 0xb65f2719 in QCoreApplication::sendEvent (this=0x9ad9260, recursive=true,
disableUpdates=true) at
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215
#34 QWidgetPrivate::sendPendingMoveAndResizeEvents (this=0x9ad9260,
recursive=true, disableUpdates=true) at kernel/qwidget.cpp:7086
#35 0xb65f2687 in QWidgetPrivate::sendPendingMoveAndResizeEvents
(this=0x9ad8ea0, recursive=true, disableUpdates=true) at
kernel/qwidget.cpp:7098
#36 0xb65f2687 in QWidgetPrivate::sendPendingMoveAndResizeEvents
(this=0x9a93e18, recursive=true, disableUpdates=true) at
kernel/qwidget.cpp:7098
#37 0xb65f2687 in QWidgetPrivate::sendPendingMoveAndResizeEvents
(this=0x9a93b60, recursive=true, disableUpdates=true) at
kernel/qwidget.cpp:7098
#38 0xb65f2687 in QWidgetPrivate::sendPendingMoveAndResizeEvents
(this=0xa0d04d8, recursive=true, disableUpdates=true) at
kernel/qwidget.cpp:7098
#39 0xb65f2687 in QWidgetPrivate::sendPendingMoveAndResizeEvents
(this=0x9149628, recursive=true, disableUpdates=true) at
kernel/qwidget.cpp:7098
#40 0xb65f2687 in QWidgetPrivate::sendPendingMoveAndResizeEvents
(this=0xa098f58, recursive=true, disableUpdates=true) at
kernel/qwidget.cpp:7098
#41 0xb65f2687 in QWidgetPrivate::sendPendingMoveAndResizeEvents
(this=0x8559d50, recursive=true, disableUpdates=true) at
kernel/qwidget.cpp:7098
#42 0xb65f8481 in QWidgetPrivate::prepareToRender (this=0x8559d50, region=...,
renderFlags=...) at kernel/qwidget.cpp:5163
#43 0xb65fd92d in QWidget::render (this=0x8559bd8, target=0xbf954f4c,
targetOffset=..., sourceRegion=..., renderFlags=...) at kernel/qwidget.cpp:4871
#44 0xb668daf2 in QPixmap::grabWidget (widget=0x8559bd8, rect=...) at
image/qpixmap.cpp:1085
#45 0xb2f76078 in Oxygen::TransitionWidget::grab (this=0x887ab00,
widget=0x8761888, rect=...) at
../../../kstyles/oxygen/transitions/oxygentransitionwidget.cpp:86
#46 0xb2f70e1e in Oxygen::LineEditData::timerEvent (this=0x887aa10,
event=0xbf955550) at
../../../kstyles/oxygen/transitions/oxygenlineeditdata.cpp:87
#47 0xb7055254 in QObject::event (this=0x887aa10, e=0xbf953bb8) at
kernel/qobject.cpp:1212
#48 0xb65954dc in QApplicationPrivate::notify_helper (this=0x847c558,
receiver=0x887aa10, e=0xbf955550) at kernel/qapplication.cpp:4300
#49 0xb659c05e in QApplication::notify (this=0xbf955958, receiver=0x887aa10,
e=0xbf955550) at kernel/qapplication.cpp:3704
#50 0xb7339f2a in KApplication::notify (this=0xbf955958, receiver=0x887aa10,
event=0xbf955550) at ../../kdeui/kernel/kapplication.cpp:302
#51 0xb7044a3b in QCoreApplication::notifyInternal (this=0xbf955958,
receiver=0x887aa10, event=0xbf955550) at kernel/qcoreapplication.cpp:704
#52 0xb7073d66 in QCoreApplication::sendEvent (this=0x847f634) at
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215
#53 QTimerInfoList::activateTimers (this=0x847f634) at
kernel/qeventdispatcher_unix.cpp:603
#54 0xb70708e4 in timerSourceDispatch (source=0x847f600) at
kernel/qeventdispatcher_glib.cpp:184
#55 0xb4f255e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#56 0xb4f292d8 in ?? () from /lib/libglib-2.0.so.0
#57 0xb4f294b8 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#58 0xb70705d5 in QEventDispatcherGlib::processEvents (this=0x84371f0,
flags=...) at kernel/qeventdispatcher_glib.cpp:412
#59 0xb6655135 in QGuiEventDispatcherGlib::processEvents (this=0x84371f0,
flags=...) at kernel/qguieventdispatcher_glib.cpp:204
#60 0xb7043059 in QEventLoop::processEvents (this=0xbf955814, flags=) at
kernel/qeventloop.cpp:149
#61 0xb70434aa in QEventLoop::exec (this=0xbf955814, flags=...) at
kernel/qeventloop.cpp:201
#62 0xb704769f in QCoreApplication::exec () at kernel/qcoreapplication.cpp:981
#63 0xb6595577 in QApplication::exec () at kernel/qapplication.cpp:3579
#64 0x08050023 in _start ()

the last bug points to this line in qabstractitemview.cpp:

int hint = d->delegateForIndex(index)->sizeHint(option, index).height();

we probably need a way to reproduce it and run valgrind on it...

*** Bug 262870 has been marked as a duplicate of this bug. ***

*** Bug 263447 has been marked as a duplicate of this bug. ***

*** Bug 267187 has been marked as a duplicate of this bug. ***

*** Bug 267559 has been marked as a duplicate of this bug. ***

If this is a duplicate of 267187, it could be closed, too.

This hasn't been reported in a long time and appears to have been fixed along with https://bugs.kde.org/show_bug.cgi?id=267187

*** Bug 299445 has been marked as a duplicate of this bug. ***

still happened with 4.2.3 - reopening...

we need a reproducible way to trigger this crash in order to fix it, or a valgrind log...

I just reproduced this issue:

- open a single project in kdev that uses the make builder
- trigger a make job (i.e. build the project)
- close the project

closing the last project results in:

kdevelop(26345)/kdevplatform (shell) KDevelop::PluginControllerPrivate::canUnload: checking can unload for: "Make Project Builder" QVariant(, )
kdevelop(26345)/kdevplatform (shell) KDevelop::PluginControllerPrivate::canUnload: checking dependencies: ("org.kdevelop.IMakeBuilder")
kdevelop(26345)/kdevplatform (shell) KDevelop::PluginController::unloadPlugin: Unloading plugin: "KDevMakeBuilder" ? MakeBuilder(0x6126460) true
kdevelop(26345)/kdevplatform (shell) KDevelop::PluginController::unloadPlugin: unloading plugin: MakeBuilder(0x6126460) "Make Project Builder"

which then also deletes the output delegate and thus crashes...

This means we either have to use shared pointers for the delegates or prevent unloading of plugins which might have still jobs running...

*** Bug 293467 has been marked as a duplicate of this bug. ***

Two questions come to mind:

a) Why is the outputview still referencing the delegate?
b) If its ok the view is still there, why does the make plugin want to keep ownership of the delegate?

This looks like mis-management of ownership of the delegate and/or not unregistering the outputview. I guess for a safer API it would be good to either make sure all views that a plugin are de-registered and the corresponding widgets deleted before the plugin is unloaded (this requires keeping track of the plugin <-> view/widgets) or remove the ownership-feature and have the framework always take ownership of the delegates and possibly also the models.

a) The outputview is still referencing the delegate, because the view showing the build-output is still there. The makebuilder plugin itself does not explicitly register a view or anything, it just runs an outputjob (the makejob). The job sets the delegate and the view uses that. And the view does not really now anything about any plugin, it just nows something about an OutputJob that will finish at some point. Even if the job has finished though, we still want to show its output until the user deletes the view.

b) Imo it "wants" to keep the ownership because the API says that this is the default and one gets the impression that it is thus the recommended way of doing it. There is even the DelegateHolder in kdevplatform/outputview ...

All in all I think this is pretty wrong on the KDevplatform side. Afaik, a delegate should actually have a one-to-one relation to a view, i.e. one should not reuse a delegate for multiple views. That is done though, as far as I can see. Every time you run an app, or a script, it will create a new view and reuse the same delegate. And of course, unloading a plugin will then crash kdevplatform.

For 4.4 this is probably too late to fix properly, yet I think for 4.5 I'll remove the ownership feature and will put the ownership always to the view. So far, I have not seen a single reason why the plugin should hold the ownership here.

I don't agree with your assessment about having a 1:1 relation between view and delegate. In particular it doesn't match the Qt api docs which would usually take ownership of things when they require a 1:1 relation anyway. But the itemview API docs explicitly don't do this. And frankly not re-using the delegate here would mean a lot of wasted memory since each delegate would need to keep its own set of brushes IIRC.

I agree though that given the plugin never sees anything about the GUI side of the outputview, it should not be allowed to take ownership of the delegate either. The delegate clearly belongs to the view.

I assume the job is not necessary to keep around and the model's ownership is already in the framework and not the plugin? Then removing the flag and moving ownership of the delegate always into the framework  should be all thats needed to fix these crashes.

Git commit f5e397be7a8088a94814a488133d572dc4167f14 by Milian Wolff.
Committed on 07/08/2012 at 13:09.
Pushed by mwolff into branch 'master'.

Let the OutputView take ownership of a job's model and delegate.

This is required to ensure proper functionality of the views
when e.g. a plugin gets unloaded. Previously, this would trigger
crashes due to access of invalid model or delegate pointers.

Now the view will stay functioning even if e.g. the MakeBuilder
gets plugin gets unloaded after a project was compiled, or even
if you close a project while it is being built.

It is still safe to access both, the model and the delegate,
from inside a job as long as the job is running. When a view
gets closed, the job gets cancelled anyways.

Sadly, this is an ABI break and thus cannot be backported to
the KDevplatform 1.4 branch...
Related: bug 207669

M  +0    -1    outputview/CMakeLists.txt
D  +0    -38   outputview/delegateholder.cpp
D  +0    -44   outputview/delegateholder.h
M  +8    -18   outputview/ioutputview.h
M  +1    -1    outputview/outputdelegate.h
M  +4    -10   outputview/outputjob.cpp
M  +20   -4    outputview/outputjob.h
M  +1    -1    outputview/outputmodel.h
M  +1    -1    plugins/execute/nativeappjob.cpp
M  +1    -1    plugins/executescript/executescriptoutputmodel.h
M  +1    -2    plugins/executescript/executescriptplugin.cpp
M  +1    -2    plugins/executescript/executescriptplugin.h
M  +3    -3    plugins/executescript/scriptappjob.cpp
M  +0    -1    plugins/executescript/scriptappjob.h
M  +4    -3    plugins/externalscript/externalscriptjob.cpp
M  +0    -1    plugins/externalscript/externalscriptplugin.cpp
M  +1    -2    plugins/externalscript/externalscriptplugin.h
M  +1    -5    plugins/standardoutputview/outputwidget.cpp
M  +4    -4    plugins/standardoutputview/standardoutputview.cpp
M  +2    -2    plugins/standardoutputview/standardoutputview.h
M  +10   -20   plugins/standardoutputview/tests/standardoutputviewtest.cpp
M  +0    -4    plugins/standardoutputview/tests/standardoutputviewtest.h
M  +13   -8    plugins/standardoutputview/toolviewdata.cpp
M  +3    -5    plugins/standardoutputview/toolviewdata.h
M  +2    -2    vcs/dvcs/dvcsjob.cpp

http://commits.kde.org/kdevplatform/f5e397be7a8088a94814a488133d572dc4167f14

Git commit 71ebc3a46cbae8dbf4f728f83ac4bfcfc3bca8bc by Milian Wolff.
Committed on 07/08/2012 at 13:50.
Pushed by mwolff into branch '4.4'.

Let the OutputView take ownership of the make output delegate.

This is basically the fix for the two bugs below that does not
require any ABI break and can thus be done in the 1.4 branch.
Related: bug 207669

M  +0    -7    projectbuilders/makebuilder/makebuilder.cpp
M  +0    -7    projectbuilders/makebuilder/makebuilder.h
M  +2    -1    projectbuilders/makebuilder/makejob.cpp
M  +1    -1    projectbuilders/makebuilder/makeoutputdelegate.h

http://commits.kde.org/kdevelop/71ebc3a46cbae8dbf4f728f83ac4bfcfc3bca8bc