Skip to content

Memory Usage too big #40

Closed
dadexix86 opened this Issue Aug 2, 2012 · 51 comments
@dadexix86

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
gpaste:
Installato: 2.8.1-1~webupd8~precise
Candidato: 2.8.1-1~webupd8~precise

on Ubuntu 12.04 with Gnome-Shell 3.4.1 and the extension $ apt-cache policy gnome-shell-extensions-gpaste
gnome-shell-extensions-gpaste:
Installato: 2.8.1-1~webupd8~precise
Candidato: 2.8.1-1~webupd8~precise

@Keruspe
Owner
Keruspe commented Aug 2, 2012

Hi,

Thank you for your report.
I'll look into this next week and stay you tuned !

@dadexix86

Ok, thanks! If you need me to do some testing I think I'll be here ;)

@cmlnet
cmlnet commented Aug 10, 2012

Got the same issue here.

@Keruspe
Owner
Keruspe commented Aug 13, 2012

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.

@cmlnet
cmlnet commented Aug 13, 2012

In my case: I use the "Empty history" functionality to solve the problem.

@Keruspe
Owner
Keruspe commented Aug 13, 2012

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 :)

@cmlnet
cmlnet commented Aug 13, 2012

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.

@whyoh
whyoh commented Aug 13, 2012

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.

@Keruspe
Owner
Keruspe commented Aug 13, 2012

I thought of deleting the history file by hand.
If you delete your only history, you're back to a default empty one

@Keruspe Keruspe closed this Aug 13, 2012
@Keruspe Keruspe reopened this Aug 13, 2012
@Keruspe
Owner
Keruspe commented Aug 13, 2012

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.

@Keruspe Keruspe closed this Aug 13, 2012
@dadexix86
@justinzyw

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:

  1. one of the gpaste thread keeps using 0%-3% CPU and the memory usage goes up by the rate of 0.1% per 15-20 seconds
  2. one of the gpaste thread keeps using 0%-8% CPU and the memory usage goes up by the rate of 0.1% per 2 seconds

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.

@Keruspe
Owner
Keruspe commented Sep 6, 2012

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

@Keruspe Keruspe reopened this Sep 6, 2012
@Keruspe
Owner
Keruspe commented Sep 29, 2012

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

@garyvdm
garyvdm commented Oct 9, 2012

2.9 fixes for me. Thanks

@dadexix86
@justinzyw

Where can I find 2.9 for Ubuntu?

@hotice
hotice commented Oct 29, 2012

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.

@Keruspe
Owner
Keruspe commented Oct 30, 2012

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:
https://github.com/Keruspe/GPaste/blob/master/libgpaste/core/gpaste-history.c#L118
which frees the memory allcated for the image:
https://github.com/Keruspe/GPaste/blob/master/libgpaste/core/gpaste-image-item.c#L113
And when an image item gets deleted, the image is also free'd:
https://github.com/Keruspe/GPaste/blob/master/libgpaste/core/gpaste-image-item.c#L129

I'd say this is a bug in gdk-pixbuf, not GPaste... But will continue to investigate.

@korbel
korbel commented Nov 6, 2012

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.

@Keruspe
Owner
Keruspe commented Nov 9, 2012

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.

@Keruspe
Owner
Keruspe commented Nov 9, 2012

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.

@kotofos
kotofos commented Nov 28, 2012

gpaste-2.9-1.fc17.i686
Fedora 17
GPaste is running as a Gnome Shell extension in the “status” area, by battery/net/volume…
Bug still occurs.

@Keruspe
Owner
Keruspe commented Nov 28, 2012

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

@Keruspe
Owner
Keruspe commented Dec 1, 2012

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 *

487bacb6eee456f445bfd20408d1f455 1298897a94fb7ade2184855061b0466b02f6fbcdea73f4aec2c6ebd4df768479.png
487bacb6eee456f445bfd20408d1f455 3759dae7fafd6d3dccc916e2efba9e6f200ab1145c4877688621c7332873d531.png
487bacb6eee456f445bfd20408d1f455 4d626418c5293757e44fa66918f99f7863aaa2490d6bc89dcb17211c98ec8d60.png
487bacb6eee456f445bfd20408d1f455 55b01eb92019f725ee33b6f407c0e5db148e59381907c6457f62f5454fb80524.png
487bacb6eee456f445bfd20408d1f455 5e58f18136df7e7545ea23129a5caf002b06aa3deca7483c142e17c980414eb3.png
487bacb6eee456f445bfd20408d1f455 611172a67b57e92b6d9053d37cf7aed790c473ab578b141ac9fdae4a60cb3eac.png
487bacb6eee456f445bfd20408d1f455 665833fabeeca6bff85c10d544b94aba18829cbd9809559997b25aec64bd899b.png
487bacb6eee456f445bfd20408d1f455 6b47fd4c95de47afb9f278e56ecfdca8b57e3aac74cbf5e4cf632cbe38d5807e.png
487bacb6eee456f445bfd20408d1f455 ca75a4937850d566fc980433bd3e06fd5f307927f5a19e0bec4fc9c9f28e85a8.png
487bacb6eee456f445bfd20408d1f455 ea8da2c78b023d74cdfbb19c48490ce5d6ba6a52d8f8b88ff23242cbeb6172ae.png
487bacb6eee456f445bfd20408d1f455 fefa2d62eea4d8f696a42b4cecacd11ad87ff1434840897710d6c3e55bd1b42b.png
keruspe@Lou ~/.local/share/gpaste/images % sha256sum *

0e0b820621cf854a8d4f603dd5c375ff4f99dd418fd5999d5dccb092c50c897d 1298897a94fb7ade2184855061b0466b02f6fbcdea73f4aec2c6ebd4df768479.png
0e0b820621cf854a8d4f603dd5c375ff4f99dd418fd5999d5dccb092c50c897d 3759dae7fafd6d3dccc916e2efba9e6f200ab1145c4877688621c7332873d531.png
0e0b820621cf854a8d4f603dd5c375ff4f99dd418fd5999d5dccb092c50c897d 4d626418c5293757e44fa66918f99f7863aaa2490d6bc89dcb17211c98ec8d60.png
0e0b820621cf854a8d4f603dd5c375ff4f99dd418fd5999d5dccb092c50c897d 55b01eb92019f725ee33b6f407c0e5db148e59381907c6457f62f5454fb80524.png
0e0b820621cf854a8d4f603dd5c375ff4f99dd418fd5999d5dccb092c50c897d 5e58f18136df7e7545ea23129a5caf002b06aa3deca7483c142e17c980414eb3.png
0e0b820621cf854a8d4f603dd5c375ff4f99dd418fd5999d5dccb092c50c897d 611172a67b57e92b6d9053d37cf7aed790c473ab578b141ac9fdae4a60cb3eac.png
0e0b820621cf854a8d4f603dd5c375ff4f99dd418fd5999d5dccb092c50c897d 665833fabeeca6bff85c10d544b94aba18829cbd9809559997b25aec64bd899b.png
0e0b820621cf854a8d4f603dd5c375ff4f99dd418fd5999d5dccb092c50c897d 6b47fd4c95de47afb9f278e56ecfdca8b57e3aac74cbf5e4cf632cbe38d5807e.png
0e0b820621cf854a8d4f603dd5c375ff4f99dd418fd5999d5dccb092c50c897d ca75a4937850d566fc980433bd3e06fd5f307927f5a19e0bec4fc9c9f28e85a8.png
0e0b820621cf854a8d4f603dd5c375ff4f99dd418fd5999d5dccb092c50c897d ea8da2c78b023d74cdfbb19c48490ce5d6ba6a52d8f8b88ff23242cbeb6172ae.png
0e0b820621cf854a8d4f603dd5c375ff4f99dd418fd5999d5dccb092c50c897d fefa2d62eea4d8f696a42b4cecacd11ad87ff1434840897710d6c3e55bd1b42b.png

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.

@Keruspe
Owner
Keruspe commented Dec 1, 2012

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!

@Keruspe Keruspe closed this Dec 1, 2012
@hotice
hotice commented Dec 2, 2012

This issue has not been fixed in GPaste 2.9.1 as you can see here: http://i.imgur.com/7rJCI.png

@Keruspe
Owner
@purpleidea

$ gpaste version
GPaste 2.99.2

I just killed the daemon after it was using 2.4Gib of Ram :(

@Keruspe
Owner
Keruspe commented Mar 27, 2013

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 ?

@purpleidea

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.

@Keruspe
Owner
Keruspe commented Mar 31, 2013

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.

@purpleidea
@BorisHollas

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.

@BorisHollas

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.

@Keruspe
Owner
Keruspe commented May 3, 2013

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.

@BorisHollas

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.

@BorisHollas

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.

@Keruspe Keruspe reopened this Jun 1, 2013
@Keruspe
Owner
Keruspe commented Jun 1, 2013

@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

@blackjackshellac

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

@Keruspe
Owner
Keruspe commented Jun 13, 2013

Were you doing anything special ? Do you have a huge history ?
Did you copy a big text or image ?

@blackjackshellac

This was on the wife's account, she said she was copying and pasting images. Nothing outrageous from the looks of this,

cd ~/.local/share/gpaste
$ du -sh .
9.4M .
$ 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.

@Keruspe
Owner
Keruspe commented Jun 16, 2013

@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:

  • The first one, I selected stuff, deleted stuff, switched to previous items in history, text only.
  • The second time I basically did the same, but manipulating images too.

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:

vgu

main (gpasted.c:74)
main (gpasted.c:76)
main (gpasted.c:77)
main (gpasted.c:78)
main (gpasted.c:81)
main (gpasted.c:82)
main (gpasted.c:85)
main (gpasted.c:87)
main (gpasted.c:107)
main (gpasted.c:127)
main (gpasted.c:129)
g_paste_clipboard_new (gpaste-clipboard.c:393)
g_paste_clipboards_manager_add_clipboard (gpaste-clipboards-manager.c:59)
g_paste_clipboards_manager_new (gpaste-clipboards-manager.c:292)
g_paste_history_init (gpaste-history.c:649)
g_paste_history_new (gpaste-history.c:685)
g_paste_daemon_on_bus_acquired (gpaste-daemon.c:543)
g_paste_daemon_on_bus_acquired (gpaste-daemon.c:547)
g_paste_daemon_on_bus_acquired (gpaste-daemon.c:551)
g_paste_daemon_on_bus_acquired (gpaste-daemon.c:555)
g_paste_daemon_own_bus_name (gpaste-daemon.c:607)
_g_paste_keybinding_new (gpaste-keybinding.c:309)
g_paste_paste_and_pop_keybinding_new (gpaste-paste-and-pop-keybinding.c:138)
g_paste_show_history_keybinding_new (gpaste-show-history-keybinding.c:59)
g_paste_settings_init (gpaste-settings.c:530)
g_paste_settings_init (gpaste-settings.c:553) 

vgu2

main (gpasted.c:74)
main (gpasted.c:76)
main (gpasted.c:77)
main (gpasted.c:78)
main (gpasted.c:81)
main (gpasted.c:82)
main (gpasted.c:85)
main (gpasted.c:87)
main (gpasted.c:107)
main (gpasted.c:129)
g_paste_clipboard_new (gpaste-clipboard.c:393)
g_paste_clipboards_manager_add_clipboard (gpaste-clipboards-manager.c:59)
g_paste_clipboards_manager_new (gpaste-clipboards-manager.c:292)
g_paste_history_init (gpaste-history.c:649)
g_paste_history_remove (gpaste-history.c:61)
g_paste_history_new (gpaste-history.c:685)
g_paste_daemon_on_bus_acquired (gpaste-daemon.c:543)
g_paste_daemon_on_bus_acquired (gpaste-daemon.c:547)
g_paste_daemon_on_bus_acquired (gpaste-daemon.c:551)
g_paste_daemon_on_bus_acquired (gpaste-daemon.c:555)
g_paste_daemon_own_bus_name (gpaste-daemon.c:607)
_g_paste_keybinding_new (gpaste-keybinding.c:309)
g_paste_paste_and_pop_keybinding_new (gpaste-paste-and-pop-keybinding.c:138)
g_paste_show_history_keybinding_new (gpaste-show-history-keybinding.c:59)
g_paste_settings_init (gpaste-settings.c:530)
g_paste_settings_init (gpaste-settings.c:553)

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.

@Keruspe Keruspe closed this Jun 16, 2013
@gregsheremeta

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
Installed Packages
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
Installed Packages
shutter.noarch 0.90-2.fc19 @fedora

greg@dauntless:~$ yum list installed kernel
Loaded plugins: langpacks, refresh-packagekit
Installed Packages

kernel.x86_64 3.11.2-201.fc19 @updates

@Keruspe
Owner
Keruspe commented Nov 10, 2013

Can you try with version 3.2.2 ?
You can disable images support in gpaste settings otherwise.

@gregsheremeta

Good call. No issues in 3.2.2. Thanks!

@jacobmischka

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.

@purpleidea

I had to stop using it because of this issue.

@Keruspe
Owner
Keruspe commented Feb 17, 2016

That's really weird, noone complained about that in more than 2 years.

What are your settings?

Do you often copy images?

@jacobmischka

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.

@Keruspe
Owner
Keruspe commented Feb 17, 2016

Ok thanks.

If it's not reproductible with images support disabled, that would explain why not that much people hit it, and why I don't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.