| Summary: | Dolphin crashed. | ||
|---|---|---|---|
| Product: | [Applications] dolphin | Reporter: | qub.box |
| Component: | general | Assignee: | Dolphin Bug Assignee <dolphin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | cfeck, hugo.pereira.da.costa |
| Priority: | NOR | ||
| Version: | 2.1 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/kde-baseapps/5343a18b50e990d75f4434b3bb70b376ab935076 | Version Fixed In: | 4.9.5 |
| Sentry Crash Report: | |||
| Attachments: | tentative patch | ||
|
Description
qub.box
2012-12-03 16:11:10 UTC
Thanks for the bug report. Looks like it might be related to Oxygen? It's actually in Qt, related to the use of the raster graphics-system. If the crash can be reproduced and happens too often try run in "native" mode: dolphin -graphicssystem native; Should fix. Nothing that we (oxyen) can do about it. @Frank ... however, there 'might' be something to be done in dolphin. It can well happen that the crash is due to some mess up in the (automatic) de-allocation chain, when exciting dolphin. If QApp (and then QStyle, and then the oxygen stuff) is deleted too late, it might be that some pointers are left dangling, because already being deleted elsewhere by Qt. Now, oxygen does not explicitely deletes anything but relies on QCache and other things to do so, so we have no control on this. But (here comes the question: is the Dolphin application deleted explicitely in the ::main() routine, or just left to automatic deletion at exit() stage ? If the latter is true: can one try to explicitely delete the qApp ? (no rush, and I can try that myself, in fact, to see if it breaks anything). Cheers, Hugo Created attachment 75611 [details]
tentative patch
@Frank again
This is typically the kind of patch I'm thinking of, which enforce deletion of DolphinApplication before hitting "return". I think it cannot make any harm, and I think I vaguely remember it fixed similar issues I had with own applications in the past.
Now, since the bug cannot be reproduced easily, I'm not sure what to make about such a patch.
Your call.
Many thanks for the quick reply and the good investigation, Hugo! Your analysis looks reasonable, and it looks harmless enough, so I'd say please commit :-) Can go into the 4.9 branch from my point of view (except for the version change, obviously), even though it's not clear yet if another release from that branch is made. No cherry-picking to master needed, we do merge regularly in kde-baseapps. I'll test for a day or two (I use dolphin enough for this to be relevant) to make sure no crash is introduced "the other way around", and will push (say by Wednesday evening). Cheers, Hugo Sounds good, great! I've also applied the patch here, I'll shout if it causes any unexpected problems. Git commit 5343a18b50e990d75f4434b3bb70b376ab935076 by Hugo Pereira Da Costa. Committed on 05/12/2012 at 21:44. Pushed by hpereiradacosta into branch 'KDE/4.9'. Added curly brackets around DolphinApplication creation and execution, to make sure it is deleted before "return 0;" is called. This might prevent random crashes due to the de-allocation chain in Qt at exit. M +6 -4 dolphin/src/main.cpp http://commits.kde.org/kde-baseapps/5343a18b50e990d75f4434b3bb70b376ab935076 Closing after previous commit, which is believed to fix this bug. |