Summary: | gwenview causes memory leak | ||
---|---|---|---|
Product: | [Applications] gwenview | Reporter: | Kristjan Ugrin <kristjan.ugrin> |
Component: | general | Assignee: | Gwenview Bugs <gwenview-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | hamboy95, myriam |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | pmap output for Xorg |
Description
Kristjan Ugrin
2008-01-05 02:00:15 UTC
have tried closing konqueror as well? Angelo Created attachment 22846 [details]
pmap output for Xorg
This shows Xorg usage after gwenview was closed, but this time I didn't use
konqueror to get into collection dir, I launched gwenview directly from bash.
Here I have a new report. This time I was sorting my collection with gwenview. After that I used "Find duplicate images..." plugin from gwenview "Plugins" menu to see if there are any duplicated images. While scanning (350 images) I went away for about an hour and half. When I returned to my computer, there were 3 duplicates found, which I deleted. After closing gwenview I saw memory usage to bee high again, ~600MB. The guilty process was Xorg. Gwenview somehow must trigger a problem in Xorg, because this doesn't happen until I use that particular application (computer is running fine for days with other applications). Xorg: --- kriko@linux:~> Xorg -version X Window System Version 7.2.0 Release Date: Wed Oct 24 14:18:36 UTC 2007 X Protocol Version 11, Revision 0, Release 7.2 Build Operating System: openSUSE SUSE LINUX Current Operating System: Linux linux 2.6.24-rc6-zen0 #16 PREEMPT Sat Jan 5 17:22:19 CET 2008 i686 Build Date: 24 October 2007 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present --- Xrestop (nothing unusual): http://files.myopera.com/kriko/other/xrestop Pmap for Xorg: http://files.myopera.com/kriko/other/pmap_xorg free -m: http://files.myopera.com/kriko/other/free If Xorg memory usage doesn't go down after leaving Gwenview, then I am afraid there is not a lot which can be done within Gwenview. Gwenview does create a lot of pixmaps for thumbnails, but Xorg should be wise enough to release them when Gwenview quit. I think this is an Xorg bug, not Gwenview. Did you try Gwenview 2.0 (from KDE4) to see if it triggers the bug too? I was able to provoke this kind of lead with gwenview from KDE4 (running under KDE3), but under same collection it kinda stops at ~100MB (101060K writable-private, 18044K readonly-private, 13136K shared, and 115052K referenced), which is a lot less than gwenview from kde3. Does this still means that something is wrong with Xorg? Le Monday 14 January 2008 00:55:14 kriko, vous avez écrit : [bugs.kde.org quoted mail] Unlike Gwenview 1.4 (KDE3), Gwenview 2.0 (KDE4) only generate visible thumbnails. Unless you scroll through your picture folder to show them all, 2.0 will probably use less memory than 1.4. If Xorg does not free the memory used by Gwenview after Gwenview has stopped, then I think there is something wrong with Xorg. Having said that, I think we should nevertheless implement some limit so that you can scroll through a huge picture folder without Gwenview storing thumbnails for every picture in memory. As Aurelien Gateau mentioned that this might be an Xorg issue, has this bug been fixed in the latest Xorg or KDE 4.7.4/Gwenview 2.7.4? I'm on a more modern system now and I cannot observe the issue anymore, it doesn't appear anymore, you can close it. Thanks. Thank you for the feedback. |