Memory leaks

I have heapshot, so I might also give that a go.

I experience the same problem. Attaching heap-shot memory snapshot after running for approx 12 hours.

Creating files in helper directory "~/local/share/docky/helpers" increases memory usage too much! So creating 10 files increases memory usage by circa 8MB.

I don't have /helpers/ in this directory. Would the bug reporter? I'm plain building from bazaar on Ubuntu 9.10...

Helpers may or may not leak. I can confirm however there are leaks:

a) in core
b) in the plugins

I ran with no helpers/plugins enabled and saw a slow leak. Running with all plugins enabled is a HUGE leak.

My money is on GIO#, as that is now part of both core and several plugins and I am fairly certain we had no leaks prior to using this.

i believe that even the basic memory usage is too high. Docks should take not more the 6-8 MB in general..
It's interesting, due to the fact the when using AWN on my laptop (with Intel X3100 graphics chip) AWN made my pc look a pentium 3 (Core 2 Due laptop), while the same AWN took 6.7 MB in my friends laptop, using an ATI chip..

I haven't tested the same issue again with Docky, but i believe the case would be the same..

Using Ubuntu 9.10 with the Docky PPA, of course

cheers

Well I've identified and fixed one huge memory leak as of rev 1197. I've also identified another memory leak but fixing it won't be so easy. The suspect method is used in quite a few different places. Further, in my testing with GLib.FileInfo, .Disposing() of the FileInfo object still seems to leak memory.

In rev 1230 memory consumption can get as high as 600-800 Mb! It's not always that high but it's always at least 150mb.
Trying to isolate it now to determine if it's in core, docklets or helpers.

Kernel: 2.6.31-20-generic

Docklets used:
- Recent Documents
- GMail
- CPU Monitor
- Weather

Helpers:
- Banshee
- Pidgin

I know exactly where it is, and am working on a fix. Please stay tuned :)

I've noticed that docky's memory usage shoots upto 400MB whenever I open and close several pictures with 'Eye of The Gnome'. Is it because the icon of docky has to change with the current picture that 'eye of gnome' is displaying?
Hope this helps you identify the leak.

I have tracked down some issues in the right-click-menu which causes for example this eog leak.
Also there were many leaks in the tileview classes. I will publish these fixes when they are ready.

I have pushed a huge fix with bzr1302, so give it a test!

My leaks aren't really fixed. It seems every time I open/close a window, usage goes up by around 200k. So we need to focus our efforts on the core dock item classes for a bit.

Still leaking with r1309 from repository

Still leaking for me as well on :

bzr docky r1309 ppa

For what it's worth it does seem to be less.. normally when I leave my pc on over night it's at around 250mb memory usage in the morning.. this time it was "only" 120.

this problem is most noticeable on systems with low memory installed.

bzr r1309 locked up my Dimension because it used over 75% of the 512mb of ram in it..

We have made much progress on this matter today.
Our latest commits have solved quite a few leaks and with trunk 1490 we noticeably reduced the memory usage.
So give it a try and report further problems.
Thank you.

Rev 1521 should fix a large leak with GMail and Weather docklets, due to how they draw their icons (it was leaking on every redraw).

I am also (still) experiencing this, I haven't been able to trace the origin myself though. So far.

Currently:
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29102 ward 20 0 1510m 1.1g 9868 S 0 38.6 72:16.47 docky

(1.1gig after a few days)

[Info 08:49:10.243] Docky version: 2.1.0 bzr docky r1615 ppa
[Info 08:49:10.254] Kernel version: 2.6.32.24
[Info 08:49:10.255] CLR version: 2.0.50727.1433

Enabled docklets:
Timer, GMail, Weather, Clock
Enabled helpers:
None

I also want to add that I am a heavy user of the timer, using it several times per day for various tasks.
GMail checks every 5 minutes.
Weather every 30 minutes using Weather Underground.

I can confirm this issue.
I use <Docky 2.1.0 bzr docky r1618 ppa> on my Ubuntu 10.04 64bit.
This morning (6:50AM) I have started Docky with 40MB and now (5:00PM) the memory is 240.7MB

Oops, forgot to mention my setting:

Docklets activated: GMail, CPU Monitor, Trash, Weather, Workspace Switcher

Helpers: Transmission, Zeitgeist Integration

We've traced the problem down to memory leaks in other libraries that we use, mostly Pango# and GIO#. I've been working on the GIO# problem, but the leaks within Pango# are much more severe, and we use pango for quite a bit.

Since Docky seems to have no state other than when the mouse is hovering over it, would a workaround be to take note of the starting memory, and when the current memory gets over X% higher (e.g. 100%), fork, exec (A fresh instance of Docky), then quit the parent?

It's not ideal, but since you've narrowed the problem to outside code (libraries), it has the virtue of freeing memory that otherwise would have been leaked.

This is what I currently do with a script I've written. I doubt y'all will want to use it, but I offer it here as an attachment as a talking piece.

I actually have a cron to restart it every 6 hours, similar idea. ;-)

And no, we won't be doing that as an official solution.

Is there a link to this Pango bug somewhere?

@Robert Dyer: Could you please show us your crontab relevant to Docky. I confirm the memroy leak but am unable to set up cron for restarting docky.

Its just a 'killall docky ; docky'... nothing fancy about it.

@Robert Dyer: Sorry that didn't work for me.

@hourly killall docky && docky
@hourly killall docky && /usr/bin/docky
@hourly killall docky && /usr/bin/cli /usr/lib/docky/Docky.exe

With all these docky services are terminated but nor resumed. Obviously I got the crontab wrong ...so was wondering.

By the way I updated to version from the ppa: 2.0.10 bzr docky r1420 pre-release and the memory leak seems to have stopped. Haven't watched it for longer periods of time, though. Hopefully this will sort out the issue.

First off I said to use a semi-colon, not '&&'. Second, you probably have to set the DISPLAY environment variable to whatever your display is. Otherwise Docky can't start.

@Robert Dyer: I did use the semi-colon as well buddy(without the quotes) but still it didn't work. Docky would terminate but not start up again. Running all those commands from the terminal would work but not in the crontab.

Don't know about the DISPLAY environment thingy...

Anyway docky seems to be working fine with the updated version. Will look out for further issues.

When you try to run any X program, it needs to know the DISPLAY. If you are running from a cron, this is not set. For *me*, this needs to be set to DISPLAY=:0 so I do:

killall docky ; DISPLAY=:0 docky

@Robert Dyer: I attempted the following options following your advice but nope, it still doesn't resume. I found the environment display variable for *my system* by looking up in NVidia X Server setttings.

killall docky ; DISPLAY=:0 docky
killall docky ; DISPLAY=bdb-laptop:0 docky
killall docky ; DISPLAY=localhost:0 docky
killall docky ; DISPLAY=:0.0 docky

Setting the display environment explicitly did not help as well. By the way I am setting the cron job by: crontab -e

Using docky 2.2 on ubuntu 10.04 64-bit. Mem leak is awful. After 9 hours uptime mem usage is at 217 MB. Noticed that the auto start command is 'docky' but when looking at the sys monitor command line column it states 'mono --debug /usr/lib/docky/Docky.exe --debug'

Docky 2.2.0
bzr docky r1805 ppa, ubuntu 10.10 64bit, 229mb mem usage at the moment, only ff needs more here.

See if there is anything here https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1427785 to help track this down. I improperly reported this as a bug in Unity, but after removing docky the reported problem disappeared. Docky was starting extra processes when waking after sleep.

'In progress' since . . 2009?