CB memory leaks and consumes all RAM on system about clipboard HOT 15 CLOSED

I hate xsel and xclip and wl-clipboard (which is why I made cb), so I'll do my best to make sure nobody has to use them. :)

from clipboard.

This has to be a bug with daemon detection as there should only be one background cb instance

from clipboard.

If there is any debug information you need I'm happy to try and collect that for you. I will also say that there are a large number of defunct cb processes that seem to linger for a long time as well.

from clipboard.

Is it possible for you to upgrade to 0.8.3? I believe it actually addressed this specific issue: https://github.com/Slackadays/Clipboard/releases/tag/0.8.3

from clipboard.

I'm actually on 0.8.3 it looks like it also has a bug where the version is reported as 0.8.2 (commit c785b5e). I had updated through linuxbrew and just run the binary directly from the release you linked and they both say 0.8.2

from clipboard.

I'm going to check out the daemon detector and see if I can reproduce this. Also, how many entries do your clipboards have? I'm wondering because you mentioned that you use CB heavily and I have no idea how many entries CB's power users are saving.

from clipboard.

My main clipboard which I use for 99% of copying has about 600 entries and 17MB of data. It's also set to be persistent.

from clipboard.

Definitely has nothing to do with the number of entries, I just started using cb a few hours ago and I have run into this issue when attempting to set it up as a clipboard provider for Neovim.

from clipboard.

@jscarrott @willothy Would you mind trying out the following command as a temporary workaround?

alias cb="killall -q cb; cb"

What this does is automatically get rid of all existing cb processes before invoking cb, so that there will only ever be one instance running. The reason we don't already do this is because there could be cb running by a different user or in a script. Therefore, we can't guarantee this method will always give the expected result, but for this particular case, it should work just fine.

from clipboard.

Yes, that's what I ended up doing temporarily. It helped but I ended up switching back to xsel for now. Cb is awesome except for this though, definitely will switch back once it's fixed :)

On that note, couldn't some kind of lockfile/pidfile be created in the users' /var/run dirs or equivalent to check for this?

from clipboard.

Fixed in bc528a6

from clipboard.

Oh awesome, thanks! That was quick lol

from clipboard.

Brilliant! Is there a timescale for when this will make it into a release, so I can stop periodically killing cb instances?

from clipboard.

Depending on how many other issue fixes I want to add, I'd say this weekend or the next one.

from clipboard.

@jscarrott 0.9.0 is out now: https://github.com/Slackadays/Clipboard/releases/tag/0.9.0.1

from clipboard.