Summary: | Dolphin crash | ||
---|---|---|---|
Product: | [Applications] dolphin | Reporter: | ruben.mueller |
Component: | general | Assignee: | Dolphin Bug Assignee <dolphin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | ali.alawami, kdebugs, sayeed.ka, v.vogelhuber |
Priority: | NOR | Keywords: | drkonqi |
Version: | 4.11.1 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/kde-baseapps/84b40da88d9821c6fc0c9ccbc3a72ec752033763 | Version Fixed In: | 4.12.0 |
Attachments: | Unit test (does not always crash, but Valgrind warns about invalid memory access) |
Description
ruben.mueller
2013-09-27 08:38:30 UTC
Thanks for the bug report! It crashes when checking the condition of the following while-loop in KFileItemModel::lessThan(const ItemData* a, const ItemData* b) const: while (a->parent != b->parent) { a = a->parent; b = b->parent; } Looks like one of the ItemData* pointers a or b became dangling, possibly because one of them had a dangling "parent" and then got replaced by it in the loop body. If this theory is correct, it would mean that an expanded folder was removed from the model, but at least one child remained in the model and kept its dangling "parent" pointer. I don't know how that could happen though... Some questions: (a) Is it correct that you used the "Details" view before the crash, and that at least one folder was expanded? (b) Was there anything special about the folder where it happened (local folder, remote file system, ...)? (c) Did you use a filter (which you can set, e.g., by pressing Ctrl+I and then entering some text)? (d) Most importantly: can you reproduce the crash if you try to repeat what you did before the first crash? Thanks for your help! Created attachment 82567 [details]
Unit test (does not always crash, but Valgrind warns about invalid memory access)
Based on the backtrace and the code, I found out that this might be related to bug 324371. I can indeed sometimes reproduce the crash when creating a tree structure like test t a test1 b test2 c test3 and then entering the folder "test" in Details View, searching for "t", and expanding and collapsing some of the folders (it also depends on the order in which the items are reported by KDirLister). I think I have an idea how this could be fixed. Git commit 84b40da88d9821c6fc0c9ccbc3a72ec752033763 by Frank Reininghaus. Committed on 07/10/2013 at 07:26. Pushed by freininghaus into branch 'master'. Make the code that removes items from KFileItemModel more robust When we remove items from the model, we called the function KFileItemModel::removeItems(const KFileItemList&, RemoveItemsBehavior). This function then looked up the indexes of the items using the hash m_items. This is wasteful in the situations when the indexes of the removed items are known in advance (like when an expanded folder is collapsed in Details View), and it can cause trouble if one item is contained in the model multiple times (can happen when searching, and a file both matches the search and is a child of a folder that matches the search). Even if expanding folders in the search results list might not be particularly useful most of the time, it makes sense to make the model more robust to prevent crashes and other unexpected behavior in such situations. This patch makes the following changes to achieve that goal: * Change the argument of removeItems() from KFileItemList to KItemRangeList. To make this work, the "look the indexes up in m_items" code is moved from that function to slotItemsDeleted(). In the other places where removeItems() is called, the indexes are calculated directly (which is not more difficult than determining the removed items as a KFileItemList, if one considers that we needed the function childItems(KFileItem) for that, which is not needed any more with this patch). * Also removeFilteredChildren() takes a KItemRangeList now. Rather than putting the parent KFileItems into a QSet for O(1) lookup (which prevents O(N^2) worst case behavior for the entire function), it uses a QSet<ItemData*> now, which should even be more efficient (hashing a pointer is cheaper than hashing a KFileItem/KUrl). Related: bug 324371 FIXED-IN: 4.12.0 REVIEW: 113070 M +77 -70 dolphin/src/kitemviews/kfileitemmodel.cpp M +2 -7 dolphin/src/kitemviews/kfileitemmodel.h M +1 -1 dolphin/src/tests/kfileitemmodelbenchmark.cpp M +58 -0 dolphin/src/tests/kfileitemmodeltest.cpp http://commits.kde.org/kde-baseapps/84b40da88d9821c6fc0c9ccbc3a72ec752033763 *** Bug 326566 has been marked as a duplicate of this bug. *** *** Bug 330022 has been marked as a duplicate of this bug. *** *** Bug 330731 has been marked as a duplicate of this bug. *** *** Bug 335249 has been marked as a duplicate of this bug. *** |