search

Keruspe / GPaste

Clipboard management system
BSD 2-Clause "Simplified" License
775 stars 55 forks source link

Memory Usage too big #40

Closed ghost closed 11 years ago

ghost commented 12 years ago

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 commented 12 years ago

Hi,

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

ghost commented 12 years ago

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

cmlnet commented 12 years ago

Got the same issue here.

Keruspe commented 12 years ago

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 commented 12 years ago

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

Keruspe commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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

Keruspe commented 12 years ago

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.

ghost commented 12 years ago

I'm sorry I did not answer but I was on a short holiday :)

What I was meaning is using the function "Empty history" provided with the extension. Doing simply that does not solve the problem, I have to kill gpasted.

2012/8/13 Marc-Antoine Perennou notifications@github.com

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.

— Reply to this email directly or view it on GitHubhttps://github.com/Keruspe/GPaste/issues/40#issuecomment-7697996.

Davide Alberelli.

On Facebook ( https://www.facebook.com/davidealberelliphoto )https://www.facebook.com/davidealberelliphoto and deviantART ( http://dadexix86.deviantart.com/ )http://dadexix86.deviantart.com/ .

justinzyw commented 12 years ago

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 commented 12 years ago

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 commented 11 years ago

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 commented 11 years ago

2.9 fixes for me. Thanks

ghost commented 11 years ago

Where can I find 2.9 for Ubuntu? Is there a repository or should I compile it by hand?

2012/10/9 Gary van der Merwe notifications@github.com

2.9 fixes for me. Thanks

— Reply to this email directly or view it on GitHubhttps://github.com/Keruspe/GPaste/issues/40#issuecomment-9252902.

Davide Alberelli.

On Facebook ( https://www.facebook.com/davidealberelliphoto )https://www.facebook.com/davidealberelliphoto and deviantART ( http://dadexix86.deviantart.com/ )http://dadexix86.deviantart.com/ .

justinzyw commented 11 years ago

Where can I find 2.9 for Ubuntu?

hotice commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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!

hotice commented 11 years ago

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

Keruspe commented 11 years ago

Did you re-launch the daemon with "gpaste dr" before testing? Are you sure the daemon is 2.9.1 too?

Le 2 déc. 2012 à 14:17, Andrew notifications@github.com a écrit :

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

— Reply to this email directly or view it on GitHubhttps://github.com/Keruspe/GPaste/issues/40#issuecomment-10929470.

purpleidea commented 11 years ago

$ gpaste version GPaste 2.99.2

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

Keruspe commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

Well I never copy images, so maybe I've been experiencing a different leak. I recently restarted, so if I run out of ram again, I'll end up killing it. I run this with the gnome-shell extension, in case that is missing info. I would suggest to run it with valgrind to be sure. Sorry I don't have more info.

J

On Sun, 2013-03-31 at 09:21 -0700, Marc-Antoine Perennou wrote:

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.

Reply to this email directly or view it on GitHub: https://github.com/Keruspe/GPaste/issues/40#issuecomment-15693583

BorisHollas commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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 commented 11 years ago

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

blackjackshellac commented 11 years ago

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 commented 11 years ago

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

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.

gregsheremeta commented 10 years ago

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 commented 10 years ago

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

gregsheremeta commented 10 years ago

Good call. No issues in 3.2.2. Thanks!

jacobmischka commented 8 years ago

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 commented 8 years ago

I had to stop using it because of this issue.

Keruspe commented 8 years ago

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

What are your settings?

Do you often copy images?

jacobmischka commented 8 years ago

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.