This method gets called each time solid notices a change, which can in some
setups be very frequent. It leaked memory as the submenus and their actions
were not deallocated properly.
Details
- Reviewers
davidedmundson meven - Group Reviewers
Frameworks - Commits
- R241:213ed50634c0: Fix memory leak in KUrlNavigatorPlacesSelector::updateMenu
Builds. User feedback: "so far so good, 160 MB Memory usage". It was ~7GiB before this patch.
Diff Detail
- Repository
- R241 KIO
- Branch
- noleak
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 21829 Build 21847: arc lint + arc unit
Make a copy, QObject::children returns const & for some reason, so gets modified during iteration.
src/filewidgets/kurlnavigatorplacesselector.cpp | ||
---|---|---|
75 | Shouldn't it be done before the call to m_placesMenu->clear(); |
src/filewidgets/kurlnavigatorplacesselector.cpp | ||
---|---|---|
75 | How would that make a difference? |
src/filewidgets/kurlnavigatorplacesselector.cpp | ||
---|---|---|
76 | Why cast? |
src/filewidgets/kurlnavigatorplacesselector.cpp | ||
---|---|---|
76 | To only delete submenus, not anything else. |
src/filewidgets/kurlnavigatorplacesselector.cpp | ||
---|---|---|
75 | Misconception on my part, .children() is not affected by .clear() |
User feedback: "so far so good, 160 MB Memory usage"
Does not sound reassuring, I guess the user meant 160 MB compared to 200MB or similar prior to patch.
Could this be the fix for https://bugs.kde.org/show_bug.cgi?id=398908, or part of it?
This leak presented itself by steadily growing memory use while something still unknown triggered solid's onMtabChanged excessively.
If that's also the case for the reporter of that bug, this should've made a big difference, otherwise only a small one.
The output of heaptrack would tell for sure.