Il 13/12/12 10:46, Michel Dänzer ha scritto:
On Mit, 2012-12-12 at 18:56 +0100, bluebubble wrote:
Il 12/12/12 17:42, Michel Dänzer ha scritto:
On Mit, 2012-12-12 at 15:48 +0100, bluebubble wrote:
Il 12/12/12 15:29, Michel Dänzer ha scritto:
On Mit, 2012-12-12 at 13:14 +0100, bluebubble wrote:
Il 12/12/12 12:35, Michel Dänzer ha scritto:
On Mit, 2012-12-12 at 12:22 +0100, bluebubble wrote:
as the title state i'm noticing huge memory leaks with oxygen-gtk
theme under KDE.
With xrestop i can see with a sample application like pidgin that for
example each time i move the mouse over a popup menu resource are
never freed (pixmaps and Misc counters grows indefinitely and also
their memory occupation).
Do the leaked resources persist when the application terminates?
This is most likely an oxygen-gtk / GTK+ issue.
yes sorry but i forgot to mention that very few resources are freed when
pidgin (or another gtk app) terminate.
Example:
ps aux before running pidgin:
[...]
That may be due to heap fragmentation (memory allocated from the heap
can only be returned to the system from the end of the allocated range,
not in the middle of it).
If the pixmaps no longer show up in xrestop, their memory is freed as
far as the X server is concerned, and they were most certainly allocated
by oxygen-gtk / GTK+.
I don't think this is due to heap fragmentation I could easily made Xorg
leak hundreds of MB and they where never freed.
How is that an argument against heap fragmentation?
Pixmaps always show up in xrestop when the application is running but if
I close the application how could I know if they where actually released?
As I said, if they weren't freed, they'd still show up in xrestop.
Sorry I wrongly read the memory reported by xrestop it isn't a great
amount that could justify the leak.
Okay.
Have you tried something like: After making the X server memory usage
grow significantly, quit pidgin, then start it again and do whatever it
is that triggers this. Does the X server memory usage start growing
again immediately?
well I found that it have a strange behavior.
Here is the steps to reproduce it:
- start pidgin
- produce the leak with the icons found in two submenu lets say submenu
"A" and submenu "B"
- close pidgin and start it again
- try to produce the leak with "A" and "B" but it doesn't "work" and no
leaks are produced
- use a third submenu "C" to produce the leak (it works)
- go back to "A" and "B" (without closing pidgin) that now are producing
the leaks again
- close pidgin and start it again
- now "A", "B" and "C" doesn't produce leaks unless I first use a fourth
submenu "D"
- loop until no more submenu are left. Now pidgin is leak safe :p
I will soon try with valgrind.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
