Summary: | Crash in [QObject::connect, QAbstractItemView::setItemDelegate, OutputWidget::changeDelegate] | ||
---|---|---|---|
Product: | [Applications] kdevelop | Reporter: | Scatterlogical <scatterlogical> |
Component: | general | Assignee: | kdevelop-bugs-null |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | abigu3282, bugs, david.nolden.kde, daviddoria, demonsboots |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Unlisted Binaries | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/kdevplatform/f5e397be7a8088a94814a488133d572dc4167f14 | Version Fixed In: | |
Sentry Crash Report: | |||
Attachments: |
crashdump1
crashdump2 crashdump3 |
Description
Scatterlogical
2009-09-17 10:21:47 UTC
If anything this backtrace shows a bug in Qt, however KCrash might have snipped too many frames hence we can't be sure. Apart from that there's no reproduction information. Why should it be a bug in Qt? More probably it's the output-view, or the multiple main window support. There is enough info in the backtrace to see where the crash happens (Thread 1). @reporter But it would be useful to know what you do when this crash happens (In reply to comment #2) > Why should it be a bug in Qt? I said "if anything". The reason is that it crashes in QObject::connect() which should not crash if I pass in two valid objects. > More probably it's the output-view, or the > multiple main window support. See, you're guessing yourself. That leads nowhere. Without more data this bugreport is simply invalid. Yeah, it's the "two valid objects" that is the critical point.. that one is more likely to cause problems than QObject::connect. Well, I have saved several more similar crash dumps if you'd like to see them. Although you may be right about it being a qt bug - I've discovered that kdevelop seems to be leaking memory severely with certain ui interactions (particularly with the menu) - which I assume causes the final crash, but it seems that other programs are repeatedly allocating ram in the same way, except I've just not had them crash the same. I'll be looking into it further tomorrow to confirm what's going on, then submit it as a qt bug if appropriate. In any case, I've attached the other dumps which might shed a bit more light, if want to be sure it's not a kdevelop bug. Created attachment 37012 [details]
crashdump1
Created attachment 37013 [details]
crashdump2
Created attachment 37014 [details]
crashdump3
the first and last are totally unrelated. The second could maybe be the same cause as the inital backtrace. Could also be fixed meanwhile. Still, without more information there's nothing we can do. *** Bug 270325 has been marked as a duplicate of this bug. *** *** Bug 303316 has been marked as a duplicate of this bug. *** *** Bug 304072 has been marked as a duplicate of this bug. *** this is valid as can be seen by the numerous duplicates, yet I still wonder how we could reproduce this and fix it... Git commit 58b9bea8e932f8b509f97b6973c80ba18f2e9c32 by Milian Wolff. Committed on 06/08/2012 at 18:54. Pushed by mwolff into branch '1.4'. Protect access of QAbstractItemDelegate pointer using a QWeakPointer. The standard output view allows plugins to provide delegates and also allows them to keep the ownership of them. While powerful, this seems to be buggy and can lead to crashes in some cases. Now we should properly detect the cases where we try to access an invalid item delegate and output a warning instead of crashing. It would still be interesting to know which plugin is responsible for this bug. M +8 -3 plugins/standardoutputview/outputwidget.cpp M +7 -2 plugins/standardoutputview/toolviewdata.cpp M +1 -1 plugins/standardoutputview/toolviewdata.h http://commits.kde.org/kdevplatform/58b9bea8e932f8b509f97b6973c80ba18f2e9c32 Does the WeakPointer help? I guess given 204399 its not really helping. But the same applies as I said in the other report. The weakpointer should prevent the crash shown here but of course it does not really "help" in the sense that 204399 is still valid and might result in the crash now instead. I have not yet found a reliable way to reproduce the crash shown here, so I can't be sure. I agree that we will have to do something more radical as outlined in 204399 to fix this issue for good. 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 204399 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 204399 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 *** Bug 307901 has been marked as a duplicate of this bug. *** *** Bug 317659 has been marked as a duplicate of this bug. *** |