Using the Gimp (copy/paste) or copying image files in nautilus makes gpaste use all my memory, making the system higly unusable.
If I delete the history nothing changes, I have to kill the process gpasted in order to return to a usable system.
I'm using $ apt-cache policy gpaste
on Ubuntu 12.04 with Gnome-Shell 3.4.1 and the extension $ apt-cache policy gnome-shell-extensions-gpaste
$ apt-cache policy gpaste
$ apt-cache policy gnome-shell-extensions-gpaste
Thank you for your report.
I'll look into this next week and stay you tuned !
Ok, thanks! If you need me to do some testing I think I'll be here ;)
Got the same issue here.
By deleting the history, you mean using the "Empty history" functionnality, not removing it by hand, right ?
It's kinda weird since, from what I see, I'm freeing everything in the history when doing that... Will check if I do not add a reference to a pixbuf that I shouldn't but seems weird.
I did not really had time to look into that yet, but I hope I'll be able to make the few modifications I want for 2.9 + at least add a settings to disable images tracking if you don't want it (+ fix this if I find out what's going on) and release 2.9.
In my case: I use the "Empty history" functionality to solve the problem.
So when you empty the history, it solves the problem ?
In the initial report: "If I delete the history nothing changes, I have to kill the process gpasted in order to return to a usable system." -> That is what I find weird.
If emptying the history solves the solution, it makes more sense to me, and I know how I'm going to handle this :)
Well, it depends on how fast the memory gets used up. If it slow enough and I notice it early enough then emptying the history solves the problem. But when it eats up memory too fast I have to switch to console and kill gpasted, then start it again and quickly emptying the history.
do you think dadexix86 might be doing "delete history" from the "Histories" tab in the daemon settings? i'm not sure what's meant to happen if you only have one history and you attempt to delete it there.
I thought of deleting the history file by hand.
If you delete your only history, you're back to a default empty one
What you said was equivalent to what I thought, and it wasn't as it has to be, so fixed that, thx.
With the two latest commits, it should be really better since I only store 0 or 1 image in the cache (depending on the kind of item which is selected in your history).
Will clean a few things up this week end and release 2.9
Feel free to reopen if it's still wrong, but everything should be way more acceptable now.
Echo here.. Empty history does not help in my Ubuntu 12.04 either.
Through htop, I spent some time and monitored how it eats up the memory. Below is my observation:
There are always three rows of /usr/lib/gpaste/gpaste and one of them keeps using the CPU (during which I am not taking any action on my laptop). There seems to be two scenarios:
both could happen when I have one picture copied at the top of the list of gpaste and it stops when I copy one text instead (ie. the text is at the top of the list). I have not yet figured out what triggers the two different scenarios through.
I am using gpaste 2.8.1-1~webupd8~precise.
Hope this could help to locate the root cause of this issue.
I'm sorry I do not have much time to spend on this because of a huge rush at work. Will be back on this soon and release 2.9 which should eventually fix this or at least provide a workaround. Should be in the next two weaks I hope.
Reopening until then
Please try with GPaste 2.9 and tell me if you still hit this issue.
You now can disable images support if this still happens and you want to use GPaste only for text
2.9 fixes for me. Thanks
Where can I find 2.9 for Ubuntu?
The issue is still there in GPaste 2.9. As a work-around, if you disable the image support, there's no more memory leak.
You can find 2.9 for ubuntu there: http://www.webupd8.org/2012/10/gpaste-gnome-shell-clipboard-manager.html
Is the leak still that bug in 2.9, or is it less violent or even more ?
Actually, when we select or add a new item, the "next" one, which was the formerly selected one becomes idle:
which frees the memory allcated for the image:
And when an image item gets deleted, the image is also free'd:
I'd say this is a bug in gdk-pixbuf, not GPaste... But will continue to investigate.
I don't know whether it is more violent or not but with a 2000x2000 image the memory consumption is increasing by ~50MB/s, and with a 600x600 image it's ~5-10MB/s.
Clearing the history neither stops the increasing, nor resets the size of allocated memory.
To stop the increasing, one must remove the image from the clipboard by putting a text into it.
The only way to reset the size of the consumed memory is killing the process.
Oh, that's an irterresting information, I did not know the memory usage increased constantly every second ! This will be of great help to debug.
You can run "gpaste dr" instead of killing the process, it will reload the daemon fron scratch.
At least with my last commit, with some debug output, I'm 100% sure that I (now) free all GdkPixbuf I'm using and their refcount is 1 just before, so if any memory still gets used afterwards, it's definitely a GdkPixbuf issue.
I'll release 2:9:1 soon.
1 Problem left with images though, When I request the image from the clipboard and ask gdk-pixbuf to compute its checksum, it randomly changes, causing GPaste think it's a new image each second.
Since only the active image is stocked, it does not affect memory usage.
GPaste is running as a Gnome Shell extension in the “status” area, by battery/net/volume…
Bug still occurs.
This is "partially" fixed in master. As I said, every image I load is correctly free'd from memory, but I still get either invalid content from the clipboard or invalid checksum from gdk-picbuf which leads sometimes to the same image being added each second one more time to the clipboard. Once I've fixed this I'll make a new release
Ok, I isalated exactly where this last bug comes from.
All of these images are the same, and the filenames are the sha256 checksum computed by glib which I use to check if the image changed.
keruspe@Lou ~/.local/share/gpaste/images % md5sum *
keruspe@Lou ~/.local/share/gpaste/images % sha256sum *
As you can see, they ARE really identical, but glib computes a wrong checksum every time.
I'll see if I either can fix this or I'll do without checksums.
This will be fixed and released really soon.
This issue is now fixed, and GPaste 2.9.1 has been released.
Thank you all for your report and all the informations you provided!
This issue has not been fixed in GPaste 2.9.1 as you can see here: http://i.imgur.com/7rJCI.png
$ gpaste version
I just killed the daemon after it was using 2.4Gib of Ram :(
Could you provide more information about what you were doing when this happened ?
Did you just updated GPaste or did you restart it after having upgraded ?
I wasn't doing anything in particular. The last two restarts I noticed my machine was using a lot more ram than normal. I finally decided to investigate, and I noticed gpasted was using 2.4Gib. So I killed it. I use gpasted with the gnome shell extension. I don't copy anything special other than text I think.
That is really weird, since it seems this release should contain the fixes for the images leak, and no other leak has been detected.
I would really be interester to see your ~/.local/share/gpaste/history.xml if it appears to happen again and if it does not contain sensitive data, it would be really helpful for debugging.
Same problem with gpaste 2.99.1-1~webupd8~raring1 on a freshly installed Ubuntu 13.04. Top shows > 1 GB memory usage for gpasted. I didn't copy any images and clearing the history didn't help.
I activated the two checkmarks to sync the clipboard with the primary selection.
Valgrind detected a memory leak. I just ran
valgrind --leak-check=yes gpaste
As I haven't compiled from source with debugging symbols I can't give any further information. I've uninstalled gpaste now.
This really is weird, I use this all day long and don't hit any memory leak so I don't seem to be able to reproduce this...
I plan to rework slightly the memory management in GPaste soon, hopefully it will fix yours...
@BorisHollas it is fully normal that valgrind report you leaks. These aren't real leaks but rather optimisations from glib. Every program using glib and/or gtk+ will have those ;) They actually corresponds to glib internal initialisations, which are only done once. Don't forget that the kernel automatically frees the memory used by a program when it exits. glib choice was to let the kernel free all this stuff for performance purpose.
A real leak is something that occurs not only once, but on a regular basis, and for now I can't find any left.
I've tried to compile GPaste but the Makefile requires build tools that are more recent than the ones included in Ubuntu 13.04. If you upload a version that compiles on 13.04 and that includes debug code I might provide more information.
Or upload a version with debugging symbols so I can run valgrind on it (there's a suppression file at http://www.gnome.org/~johan/gtk.suppression to prevent the messages with gtk). At least you should re-open this bug.
@BorisHollas There are tarballs available with which you don't even need to run autotools (see README)
Those suppression never really worked for me, leaving tons of unsuppressed leaks from glib/gtk
Data point: using gpaste 3.0.2 on fedora.18, got Oom last night on gpasted consuming 4GB of vm memory, on a system with 6GB of ram, and no swap.
[537029.682986] Out of memory: Kill process 3601 (gpasted) score 740 or sacrifice child
[537029.683062] Killed process 3601 (gpasted) total-vm:4913772kB, anon-rss:4414996kB, file-rss:744kB
Were you doing anything special ? Do you have a huge history ?
Did you copy a big text or image ?
This was on the wife's account, she said she was copying and pasting images. Nothing outrageous from the looks of this,
$ du -sh .
$ find -ls
30236678 4 drwxr-xr-x 3 wifey wifey 4096 Jan 25 16:14 .
30178354 12 -rw-r--r-- 1 wifey wifey 9102 Jun 12 16:35 ./history.xml
30236673 4 drwx------ 2 wifey wifey 4096 Jun 12 16:35 ./images
30147125 3048 -rw-r--r-- 1 wifey wifey 3121034 Jan 25 16:15 ./images/b7c118c26ea54922038bda988a9677a1c265040dae756e7c02e214c281cbda69.png
30147301 1256 -rw-r--r-- 1 wifey wifey 1285554 Mar 27 19:49 ./images/cee1c786c3b8d22e27e7417cb6d4044ce60d2ccf9be5e62b1a08ec688458808d.png
30147201 2996 -rw-r--r-- 1 wifey wifey 3066653 Apr 30 15:17 ./images/c29720de1e314a5ca0fb874e369616a9315a8df1b48cec76553cccdc9bbbc499.png
30146809 60 -rw-r--r-- 1 wifey wifey 57922 Jun 12 16:35 ./images/a4a562ccff4c8b6a16f0638c4fe17add612c0d3355e2c31d2584364eae81367b.png
30175033 932 -rw-r--r-- 1 wifey wifey 952647 Jun 10 12:44 ./images/138355314f0e9d2ef9b519a1252517006d5ef2756f8833aaaf08cc00bdbe78f6.png
30175120 60 -rw-r--r-- 1 wifey wifey 60729 Jun 12 16:35 ./images/b4074c72d3dd0396f20e518255761f838f7ae6d79ca6467cb9eeed1e65704c5b.png
30178974 504 -rw-r--r-- 1 wifey wifey 512909 Jan 25 16:14 ./images/09dc6070d79929e0b5bbe5c07e567454b12ae5cc39f244d721b54464da6d1fdb.png
30147204 656 -rw-r--r-- 1 wifey wifey 668722 Jun 12 13:03 ./images/625c167c6db5f286e23775fe88c4227a9bab24896a8955f66df69fb73295e2df.png
I did notice that her gpasted daemon was pretty big last night, but didn't really think anything of it. Now it seems not to be running so I guess the extension was disabled by gnome shell? I'm doing this remotely so I can't really add anything else right now. Let me know if I can be of any help.
@blackjackshellac Juste to be sure, you're using GPaste 3.0.2 right ?
I just made a bunch of valgrinding. For valgrind to report thing correctly, the daemon has to exit, so I basically commented the exec line from the reexec feature (https://github.com/Keruspe/GPaste/blob/master/src/gpasted/gpasted.c#L63) so that when I run gpaste dr it exits.
launched it with
LD_LIBRARY_PATH="./libgpaste/settings/.libs:./libgpaste/settings/ui/.libs:./libgpaste/common/.libs:./libgpaste/client/.libs:./libgpaste/core/.libs:./libgpaste/daemon/.libs:./libgpaste/keybinder/.libs" G_SLICE=always-malloc valgrind -v --leak-check=full ./bin/.libs/gpasted &> vg
Then I did two series of tests:
Each time, the result was stored in a file named vg
I then extracted from it the stuff which actually comes from GPaste:
grep -E 'g_?paste' vg | sort -u | grep '==' | sed s/==.*==// | sed '$d' | sed '$d' | cut -d ':' -f 2- > vgu
For the first test, the result was stored in vgu, for the second in vgu2
Here is the contents of these files:
The only difference between those two is one from g_paste_history_remove, which is an internal glib leak in g_local_file_delete.
All of the other "leaks" are coming from initialisations, in the glib internals.
Note that "leaks" at initialisation are not real leaks, since they only appear once, and it's a wanted behaviour from glib not to free them by hand, for performance purpose, since they will automatically be free'd by the kernel at exit.
No matter how I try, I cannot reproduce this issue anymore (since GPaste 2.9.1).
If there is still an issue I can't reproduce, it's definitely not the one for which this bug was initially opened, so closing it back now.
Feel free to open a new one describing exactly how you managed to get gpasted wrong, and I'll be happy to fix it.
Note that soon, glib will allow us to choose whether we want or not to make it actually free initialisation stuff by itself, not leaving it to the kernel. Will enable it in GPaste as soon as it's available, maybe it helps.
See https://git.gnome.org/browse/glib/log/?h=wip/gcleanup and https://bugzilla.gnome.org/show_bug.cgi?id=627423 for reference.
I'm still seeing this with gpaste 3.0.2 on Fedora 19. I notice it after doing screen captures with Shutter (so, an image copy). It eats up CPU and memory. I have to kill it.
top - 08:44:50 up 3 days, 15:18, 4 users, load average: 0.13, 0.15, 0.14
Tasks: 226 total, 1 running, 223 sleeping, 0 stopped, 2 zombie
%Cpu(s): 1.9 us, 0.2 sy, 0.0 ni, 97.7 id, 0.0 wa, 0.1 hi, 0.1 si, 0.0 st
KiB Mem: 16386848 total, 16184140 used, 202708 free, 280476 buffers
KiB Swap: 8265724 total, 876 used, 8264848 free, 2717984 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2979 greg 20 0 8127792 7.234g 9228 S 5.3 46.3 6:21.42 gpasted
10494 greg 20 0 4791964 992400 45344 S 0.0 6.1 49:13.95 java
3392 greg 20 0 1568328 452084 34056 S 0.0 2.8 16:44.63 chrome
greg@dauntless:~$ yum list installed gpast*
Loaded plugins: langpacks, refresh-packagekit
gpaste.x86_64 3.0.2-1.fc19 @fedora
gpaste-libs.x86_64 3.0.2-1.fc19 @fedora
greg@dauntless:~$ yum list installed shutter
Loaded plugins: langpacks, refresh-packagekit
shutter.noarch 0.90-2.fc19 @fedora
greg@dauntless:~$ yum list installed kernel
Loaded plugins: langpacks, refresh-packagekit
kernel.x86_64 3.11.2-201.fc19 @updates
Can you try with version 3.2.2 ?
You can disable images support in gpaste settings otherwise.
Good call. No issues in 3.2.2. Thanks!
gpaste 3.18.3-1 I still to this day have gpaste using 100% of my system's memory whenever it thinks it's convenient. Happens every few days. I don't think this is fixed, or I'm doing something wrong somehow.
I had to stop using it because of this issue.
That's really weird, noone complained about that in more than 2 years.
What are your settings?
Do you often copy images?
I have track clipboard changes, enable the gnome-shell extension, save history, and image support enabled. I copy images fairly often, usually using the gnome screenshot hotkey to capture a region and save it to clipboard. I'm pretty sure that's what causes it.
It's hard to tell exactly because I don't often notice until a while later when I have no memory left. I just yesterday disabled image support, I'll report back if it happens again since I've done so.
If it's not reproductible with images support disabled, that would explain why not that much people hit it, and why I don't.