Only one item in history (ie: Gpaste doesn't keep history anymore)

[axelsimon]

I recently upgraded to Fedora 34 and i discovered that my Gpaste history is empty, save for one item: the last thing copied.

It appears that Gpaste 3.40.2 only keeps the last item in history, even though my history is currently set at 200 items.

Screenshot of Gpaste:

Is this a known issue? I couldn't find any other issue mentioning the same problem.

Happy to try and provide further info.

[axelsimon]

Well this is strange, my history simply started working again a few hours after i created this issue. I will close it.

[sferra]

I'm having this issue and it makes Gpaste (v3.40.2 on Ubuntu 21.10) useless.

[sferra]

Executing gpaste-client daemon-reexec seems to fix this issue.

[axelsimon]

@Keruspe I'm reopening this, as it's still an issue. I'm still regularly discovering my clipboard history reduced to one item, with all other items lost (which is pretty bad, given once you have a clipboard manager, you start relying on it to remember things for you temporarily). And, as described in the original, when the problem happens, the history in gpaste is capped at 1 item.

My solution so far is just pkill gpaste-daemon followed by gpaste-client but @sferra's option seems like the same thing but qiucker and cleaner, so i'll try that next time.

[baurmatt]

Just wanted to report that I'm experiencing the same issues since ~6 months on Arch Linux. Currently running gpaste 3.42.6-1 on Gnome 41.3-1. My workaround is to killall gpaste-daemon and restart the app. It seems to me that this issue happens after my laptop comes back from suspend, but that's just a hunch right now.

[Keruspe]

Did you see it happen with 3.42.6 too? Any logs in the journal?

[baurmatt]

Did you see it happen with 3.42.6 too?

I guess this goes out to @axelsimon and @sferra :)

Any logs in the journal?

Nothing interesting:

$ journalctl --since today | grep gpaste
Mär 08 11:11:10 T14s gpaste-daemon[2040]: Stop signal received, exiting

[Keruspe]

On Tue 8 Mar 2022 at 13:09, Matthias Baur @.***> wrote:

Did you see it happen with 3.42.6 too?

I guess this goes out to @axelsimon https://github.com/axelsimon and @sferra https://github.com/sferra :)

No, this was for you, you’ve seen it with 3.42.6 running?

Any logs in the journal?

Nothing interesting:

$ journalctl --since today | grep gpaste

Mär 08 11:11:10 T14s gpaste-daemon[2040]: Stop signal received, exiting

— Reply to this email directly, view it on GitHub https://github.com/Keruspe/GPaste/issues/365#issuecomment-1061710810, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWNXVDO63NRH4HYGIZJ5DU647PVANCNFSM5EE63T5Q . You are receiving this because you were mentioned.Message ID: @.***>

[baurmatt]

Yes, I've experienced it this morning with 3.42.6. I couldn't find anything interesting in journald which matched the search term gpaste

[Keruspe]

Does coredumpctl list anything?

[baurmatt]

Nope, nothing that matches gpaste.

[baurmatt]

I suspect for a while that this problem happens after updates of dependencies are installed and the computer/service isn't restarted. Today I ran into the problem again and check the updates I've installed last night:

gtk3 (1:3.24.33-1 -> 1:3.24.33-2) gnome-shell (1:41.4-1 -> 1:41.5-1) gobject-introspection-runtime (1.70.0-5 -> 1.72.0-1)

Those are the dependencies of gpaste which had updates installed. Does this make any sense?

Any idea how I'm supposed to debug this when it is currently happening?

[olivergondza]

I observe this sporadically on Arch Linux with 3.42.6. gpaste-client daemon-reexec do fix it. I found no recent/relevant coredumps, nothing relevant in journal either. However, I have not updated any dependency since the last reboot, and this problem appeared anyway. This is happening on wayland.

Is there a way I can collect more input?

[joewilliams]

I am having the same problem on ubuntu 21.04 and gpaste 3.42.6.

[madicnikola]

I am having the same problem on ubuntu 22.04 and gpaste 3.42.6. Executing this command gpaste-client daemon-reexec fixes the issue for me. Jornal logs -> journalctl --since today | grep gpaste

Jun 15 08:18:13 Vostro-15 dbus-daemon[1020]: [session uid=1000 pid=1020] Activating via systemd: service name='org.gnome.GPaste.Ui' unit='org.gnome.GPaste.Ui.service' requested by ':1.76' (uid=1000 pid=1674 comm="/usr/libexec/gpaste/gpaste-daemon " label="unconfined")
Jun 15 08:18:14 Vostro-15 gpaste-ui[6506]: gtk_widget_event: assertion 'WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
Jun 15 08:46:18 Vostro-15 gpaste-daemon[1674]: Stop signal received, exiting
Jun 15 10:41:24 Vostro-15 dbus-daemon[1048]: [session uid=1000 pid=1048] Activating via systemd: service name='org.gnome.GPaste.Ui' unit='org.gnome.GPaste.Ui.service' requested by ':1.76' (uid=1000 pid=1696 comm="/usr/libexec/gpaste/gpaste-daemon " label="unconfined")
Jun 15 11:58:23 Vostro-15 dbus-daemon[1048]: [session uid=1000 pid=1048] Activating via systemd: service name='org.gnome.GPaste.Ui' unit='org.gnome.GPaste.Ui.service' requested by ':1.76' (uid=1000 pid=1696 comm="/usr/libexec/gpaste/gpaste-daemon " label="unconfined")
Jun 15 14:52:17 Vostro-15 dbus-daemon[1048]: [session uid=1000 pid=1048] Activating via systemd: service name='org.gnome.GPaste.Ui' unit='org.gnome.GPaste.Ui.service' requested by ':1.76' (uid=1000 pid=1696 comm="/usr/libexec/gpaste/gpaste-daemon " label="unconfined")
Jun 15 14:52:26 Vostro-15 dbus-daemon[1048]: [session uid=1000 pid=1048] Activating via systemd: service name='org.gnome.GPaste.Ui' unit='org.gnome.GPaste.Ui.service' requested by ':1.76' (uid=1000 pid=1696 comm="/usr/libexec/gpaste/gpaste-daemon " label="unconfined")
Jun 15 14:53:40 Vostro-15 sudo[28604]: madicnikola : TTY=pts/5 ; PWD=/home/madicnikola ; USER=root ; COMMAND=/usr/bin/apt install gnome-shell-extensions-gpaste gpaste
Jun 15 14:53:45 Vostro-15 dbus-daemon[1048]: [session uid=1000 pid=1048] Activating via systemd: service name='org.gnome.GPaste.Ui' unit='org.gnome.GPaste.Ui.service' requested by ':1.76' (uid=1000 pid=1696 comm="/usr/libexec/gpaste/gpaste-daemon " label="unconfined")
Jun 15 14:53:49 Vostro-15 dbus-daemon[1048]: [session uid=1000 pid=1048] Activating via systemd: service name='org.gnome.GPaste.Ui' unit='org.gnome.GPaste.Ui.service' requested by ':1.76' (uid=1000 pid=1696 comm="/usr/libexec/gpaste/gpaste-daemon " label="unconfined")
Jun 15 14:54:13 Vostro-15 dbus-daemon[1048]: [session uid=1000 pid=1048] Activating via systemd: service name='org.gnome.GPaste.Ui' unit='org.gnome.GPaste.Ui.service' requested by ':1.76' (uid=1000 pid=1696 comm="/usr/libexec/gpaste/gpaste-daemon " label="unconfined")
Jun 15 14:54:16 Vostro-15 dbus-daemon[1048]: [session uid=1000 pid=1048] Activating via systemd: service name='org.gnome.GPaste.Ui' unit='org.gnome.GPaste.Ui.service' requested by ':1.76' (uid=1000 pid=1696 comm="/usr/libexec/gpaste/gpaste-daemon " label="unconfined")
Jun 15 14:55:31 Vostro-15 dbus-daemon[1048]: [session uid=1000 pid=1048] Activating service name='org.gnome.ScreenSaver' requested by ':1.522' (uid=1000 pid=31675 comm="/usr/libexec/gpaste/gpaste-daemon " label="unconfined")
Jun 15 14:55:33 Vostro-15 dbus-daemon[1048]: [session uid=1000 pid=1048] Activating via systemd: service name='org.gnome.GPaste.Ui' unit='org.gnome.GPaste.Ui.service' requested by ':1.522' (uid=1000 pid=31675 comm="/usr/libexec/gpaste/gpaste-daemon " label="unconfined")
Jun 15 14:55:35 Vostro-15 dbus-daemon[1048]: [session uid=1000 pid=1048] Activating via systemd: service name='org.gnome.GPaste.Ui' unit='org.gnome.GPaste.Ui.service' requested by ':1.522' (uid=1000 pid=31675 comm="/usr/libexec/gpaste/gpaste-daemon " label="unconfined")
Jun 15 15:15:26 Vostro-15 dbus-daemon[1048]: [session uid=1000 pid=1048] Activating via systemd: service name='org.gnome.GPaste.Ui' unit='org.gnome.GPaste.Ui.service' requested by ':1.522' (uid=1000 pid=31675 comm="/usr/libexec/gpaste/gpaste-daemon " label="unconfined")
Jun 15 15:19:49 Vostro-15 dbus-daemon[1048]: [session uid=1000 pid=1048] Activating via systemd: service name='org.gnome.GPaste.Ui' unit='org.gnome.GPaste.Ui.service' requested by ':1.522' (uid=1000 pid=31675 comm="/usr/libexec/gpaste/gpaste-daemon " label="unconfined")

[rbjorklin]

This seems like a duplicate of #354, is that correct?

[sferra]

This seems like a duplicate of #354, is that correct?

Yes, it looks like the same issue.

[axelsimon]

I just checked what journalctl --since today | grep gpaste returns, having just run into the issue again, and i get tens of lines of: Oct 10 12:04:16 laptop gpaste-daemon[882551]: g_paste_history_private_check_memory_usage: assertion 'biggest' failed

So it seems to be the same issue.

[Keruspe]

You just might have found something, thanks!

On Mon 10 Oct 2022 at 16:57, axel simon @.***> wrote:

I just checked what journalctl --since today | grep gpaste returns, having just run into the issue again, and i get tens of lines of: Oct 10 12:04:16 laptop gpaste-daemon[882551]: g_paste_history_private_check_memory_usage: assertion 'biggest' failed

It seems to be a different issue then?

— Reply to this email directly, view it on GitHub https://github.com/Keruspe/GPaste/issues/365#issuecomment-1273443939, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWNXQE4MPUCZFMXX23PB3WCQVFVANCNFSM5EE63T5Q . You are receiving this because you were mentioned.Message ID: @.***>

[dumbasPL]

Can confirm, I also have my journal spanned with the same exact error message.

[Keruspe]

Ok, I'm pretty sure now that I know exactly what is going on and I have a local fix.

When detecting a growing line and the active item is the biggest in history, we hit this problem.

[fkr-0]

Hey I recently built from Master (cad0e45dfa3e56bbe5e7467496a429017876bf74) and hit the problem again, I think:

Nov 24 00:09:55 sys gpaste-daemon[1697]: g_paste_history_private_check_memory_usage: assertion 'biggest' failed
Nov 24 00:10:03 sys gpaste-daemon[1697]: g_paste_history_private_check_memory_usage: assertion 'biggest' failed

if I can help clarifying the issue please let me know. And thanks for the great software.

[Keruspe]

Thanks, will give it yet another thorough look and try and make a release too.

Just checking : you're 100% sure you were running the daemon built from master and not the one from your system when this happened right? DBus activation can easily trick you with this if you don't manually start the daemon

[fkr-0]

yes, i can confirm that it is still happening

Dec 05 22:35:39 sys gpaste-daemon[2662916]: g_paste_history_private_check_memory_usage: assertion 'biggest' failed
Dec 05 22:35:39 sys gpaste-daemon[2662916]: g_paste_history_private_check_memory_usage: assertion 'biggest' failed
Dec 05 22:35:46 sys gpaste-daemon[2662916]: g_paste_history_private_check_memory_usage: assertion 'biggest' failed
Dec 05 22:36:12 sys gpaste-daemon[2662916]: g_paste_history_private_check_memory_usage: assertion 'biggest' failed
Dec 05 22:37:15 sys gpaste-daemon[2662916]: g_paste_history_private_check_memory_usage: assertion 'biggest' failed

[levihb]

Just wanted to say that this is still happening regularly for me. I don't know what it is, sometimes I'll open it and it'll have a single item, then other times I'll open it, and it'll be working fine.

E.g. at the moment it's broken for some reason. No I have not updated any dependencies since I turned the system on. And I'm completely missing the errors people here posted.

If someone has a workaround or similar that'd be great. Because this is severely disrupting my workflow to the point where I'm just considering giving up on it. If there's anyway I can help please do tell me.

[Keruspe]

What is the output of ‘gpaste-client daemon-version’ ? Do you have any logs of when this happens?

On Sun 19 Feb 2023 at 08:06, levihb @.***> wrote:

Just wanted to say that this is still happening regularly for me. I don't know what it is, sometimes I'll open it and it'll have a single item, then other times I'll open it, and it'll be working fine.

E.g. at the moment it's broken for some reason. No I have not updated any dependencies since I turned the system on. And I'm completely missing the errors people here posted.

If someone has a workaround or similar that'd be great. Because this is severely disrupting my workflow to the point where I'm just considering giving up on it. If there's anyway I can help please do tell me.

— Reply to this email directly, view it on GitHub https://github.com/Keruspe/GPaste/issues/365#issuecomment-1435911317, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWNXTJIEWXV6FKFZWPCPTWYHBANANCNFSM5EE63T5Q . You are receiving this because you modified the open/close state.Message ID: @.***>

[stolyarchuk]

Having the same problem after suspending and resuming on my latest Fedora system. It appears randomly, not after every resuming. Solved it with restarting gpaste systemd user service after PC been resumed.

[levihb]

@Keruspe Version 43.1. No logs that I can see.

I can't figure out the cause or certain - but I'm fairly sure it's the same as @stolyarchuk. When coming out of sleep mode for some reason it just shows a single history item, whatever is currently on the clipboard.

[Keruspe]

Not sure what could cause this yet, but that's definitely a lead. I'll try to reproduce on my end. Logs would help though until I can reproduce

[stolyarchuk]

i'm using this systemd service as a workaround

[Unit]
Description=Restart GPaste after resume from sleep/suspend
After=suspend.target

[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl --machine your_username_here@.host --user restart org.gnome.GPaste.service

[Install]
WantedBy=suspend.target

hope this could help someone before @Keruspe finds the solution

[igolovic]

I can confirm this on Debian GNU/Linux 11 (bullseye) - 64-bit - GNOME 3.38.5 - X11 (Wayland disabled)

[bobi32]

So, wanting to investigate the journal entry, I kept a debugger open for a few days until the issue triggers again the call to g_return_if_fail(biggest) in gpaste-history.c::g_paste_history_private_check_memory_usage

It turns out it happens while my history is full and starts to discard old entries when adding new ones. With first investigations, when it first happens biggest is NULL, leading me to think the entry matching the priv->biggest_uuid has been discarded, thus resolved to NULL by the **_get_item_by_uuid call.

The trick is, this keeps happening afterwards (the whole thing: biggest entry being resolved to NULL hence the g_return_if_fail triggered) whenever I copy some new stuff; the history is not yet broken atm though (but I am pretty sure it will be eventually)

I cannot pretend I understand plainly how gpaste works, but my two cents are that a new biggest entry might be looked for whenever priv->biggest_uuid turns out stale.

Something like this instead of / before the call to g_return_if_fail(biggest) maybe:

if (NULL == biggest) {
    g_paste_history_private_elect_new_biggest(priv);
    biggest = g_paste_history_private_get_item_by_uuid (priv, priv->biggest_uuid, NULL);
}

(or perhaps you’ll want to trigger the elect in g_paste_history_private_check_size when the size of the element to remove matches priv->biggest_size)

[batiukmaks]

Hello! For several weeks this command line gpaste-client daemon-reexec helps me to restart the GPaste. But I am annoyed of it, how can I make my GPaste work forever?

[Keruspe]

Which version are you running ? Should be ok if it's up to date

[bobi32]

Even with the latest build the issue seems unfixed. With more tests I came up with a repeatable use case:

• For a history of 100 with this file history.xml.gz
  1. Stop GPaste daemon: systemctl --user stop org.gnome.GPaste.service
  2. Replace history: gzip -cd history.xml.gz > ~/.local/share/GPaste/history.xml
  3. Start GPaste daemon: systemctl --user start org.gnome.GPaste.service
  4. Copy something not already in the history: echo -n 99 | gpaste-client
• Boom, history’s broken.

As you will see, the history is not randomly crafted:

• Already full.
• The oldest entry is by far the largest one and has a mime value attached (from my tests that means I copied it from ctrl+C; using gpaste-client does not seem to trigger the computation of this mime value).
• Said mime value is way larger in size than the total concatenation of all 100 entries as pure text.

This last point is the most important one. Indeed while digging further I realized that when copying new stuff, thus discarding this last relatively huge entry, history size underflows. Expectedly, that leads to a loop that empties the history, trying to get back to a more realistic size than ~UINT64_MAX. As observed, copying new entries hardly help, since the history size won’t get recomputed until the daemon is restarted (which in itself should not be an issue if the underflow had not happened in the first place).

Now as to why the history size underflows, it very much seems like the history size is computed as the sum of pure-text length of all entries in the history, while every entry size is computed as the total size the entry “weighs” in the history.xml file, meaning the length of the text itself + the length of the mime text-html value.

For what it’s worth, the underflow appends in gpaste-history.c::g_paste_history_private_check_size, at the only step this for loop seems to take:

for (GList *_history = history; _history; _history = g_list_next (_history))
            priv->size -= g_paste_item_get_size (_history->data);

No definite idea what to fix though.

[Keruspe]

Thanks a lot for this deep analysis!

We're now à the third (?) issue behind this symptom.

I'll give it a look soon

[bobi32]

You’re welcome!

Pretty sure my first diagnosis was wrong, I would count that as a second issue.

Down the line what was really necessary was to find a way to keep track of past changes on the history file. Once done (hint: incron + local git repository), it was just a matter of identifying the breaking change, get the history before & after, and at last replay the change a bit until a plausible cause is found rather than guessed.

Anyway, if the use case I came up with turns out not as reproducible as expected, here’s the configuration I run gpaste with:

$ dconf dump /org/gnome/GPaste/
[/]
history-name='history'
max-memory-usage=uint64 5
track-changes=true
track-extension-state=true

For the rest I must be sticking to defaults I guess.

[galvani]

Hello! For several weeks this command line gpaste-client daemon-reexec helps me to restart the GPaste. But I am annoyed of it, how can I make my GPaste work forever?

yeah, and you cannot find this line in gpaste, right?! ;-)

[axelsimon]

I'm still hitting this error regularly. This is 44.0 on Fedora 38 with GNOME 44.5. And I've just gpaste-client daemon-reexeced to no avail.

update: I ran that command a few times and while it refused to pick up some text in tmux at first, now it's starting to copy stuff again.

Can we reopen, @Keruspe ? This is sadly clearly not fixed :disappointed:

[Keruspe]

Which version of GPaste are you running ? It was fixed in 44.1

[rbjorklin]

I was about to chime in and agree with @axelsimon but as it turns out 44.1 hasn't landed in Fedora 38 yet unless you enable the updates-testing repo.

This worked for me: dnf upgrade --enablerepo=updates-testing gnome-shell-extension-gpaste gpaste gpaste-ui

[axelsimon]

Thanks @rbjorklin, I'm now on 44.1 using your tip. Looking forward to not seeing this bug anymore :wink:

[Keruspe]

We'll definitely open it back if you hit it again, but pretty confident @bobi32 fix was the proper one

[dumbasPL]

pretty confident @bobi32 fix was the proper one

Yeah, ever since 44.1 I haven't experienced a single problem related to this.