Logseq interface freezes when trying to copy text

matejc commented 3 weeks ago

Search first

[X] I searched and no similar issues were found

What Happened?

Whenever I copy more blocks of lines (multiple bullet points) the whole interface become unresponsive and after few seconds, Logseq turns completely white.

I am observing this behavior for few versions back (cant remember when it started).

It could be because I am using:

Wayland
SwayWM
NixOS (package is from nixpkgs, installed through Nix)

Checking this further, it appears to happen when link is in the structure. But it happens even if it is not selected/copied. And it does not happen each time that I copy.

Reproduce the Bug

Select multiple lines of bullet points - to trigger per-bullet-point selection and not character-to-character selection
Ctrl+C or Right click on the selection and click Copy
Interface freezes immediately

Expected Behavior

To copy the text into clipboard and not freeze

Screenshots

It appears to freeze if there is a link in located in the structure of bullet points (with this selection it froze):

Desktop or Mobile Platform Information

NixOS unstable channel Logseq 0.10.9 (Electron 27.3.11)

Additional Context

No response

Are you willing to submit a PR? If you know how to fix the bug.

[x] I'm willing to submit a PR (Thank you!)

sigmonsays commented 2 weeks ago

this happens to me too, trying to do both ctl-c or ctl-x (copy or cut)

I am on nixos, i3 window manager. logseq is installed from nixos, it's version logseq-0.10.9/

asandikci commented 2 weeks ago

I have the same problem with NixOS 24.05 + Wayland + KDE Plasma 6 + Logseq 0.10.9

asandikci commented 2 weeks ago

Maybe related with electron version in NixOS? See https://github.com/NixOS/nixpkgs/issues/282430

jlbribeiro commented 2 weeks ago

While #10549 reports a different situation, many of the comments there specifically report this crash-during-block-copying. See my comment on that issue for a summary of all reports. As on that issue, I propose you open Logseq via the terminal and attempt to reproduce the issue, and share the logs, so we can compare with the ones in that issue.

tl;dr: not necessarily nixpkgs-specific, but nixpkgs seems to reliably reproduce the issue.

matejc commented 2 weeks ago

Logs from terminal with reproduced issue, are:

(rsapi) init loggers
20:14:35.342 › Logseq App(0.10.9) Starting... 
20:14:35.345 › restore proxy settings {:type "system"}
20:14:35.346 › set proxy to {:type "system"}
20:14:37.367 › :electron.handler/watch-dir {:path "/home/matejc/.logseq/config"}
[299307:0609/201438.509879:ERROR:object_proxy.cc(577)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[299307:0609/201438.510209:ERROR:object_proxy.cc(577)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[299307:0609/201438.510519:ERROR:object_proxy.cc(577)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
zsh: killed     logseq

At the end I killed it with SIGKILL(9). There are no lines in the logs for the time when I copy, all the log lines are from the startup of the app itself (Except the zsh: killed logseq which happened at the time of kill).

How to get debug log entries?

dailyherold commented 1 week ago

Same happening for me on 0.10.9 installed via nixpkgs. Happy to also help generate some debug logs and contribute but am in same boat as @matejc on needing guidance. Tailed the config directory's log file but weren't verbose, any tips on increasing that?

acaloiaro commented 1 day ago

It does seem like nixpkgs is the common theme here. I'm also a NixOS user and I've had this same issue across multiple versions of Logseq. I noticed that exporting to HTML can also trigger it.

I would add one detail to the original reported issue above. For me, this issue only triggers after I've successfully copied content once. Afer that, it locks up 100% of the time.

These warnings may appear when I run logseq from the terminal and copy blocks, though I imagine they're likely unrelated.

Warning: terminator_CreateInstance: Received return code -3 from call to vkCreateInstance in ICD /nix/store/hggpnywm6l7cfh2ml1ynm50ap9x4f9rn-mesa-24.0.7-drivers/lib/libvulkan_virtio.so. Skipping this driver.
Warning: terminator_CreateInstance: Received return code -3 from call to vkCreateInstance in ICD /nix/store/hggpnywm6l7cfh2ml1ynm50ap9x4f9rn-mesa-24.0.7-drivers/lib/libvulkan_dzn.so. Skipping this driver.

And this may be more relevant. When Logseq is locked up and I control + C from the terminal, this error always appears

^CError sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at WebFrameMain.send (node:electron/js2c/browser_init:2:84707)
    at WebContents.send (node:electron/js2c/browser_init:2:70186)
    at $electron$window$close_handler$$ (/nix/store/hsb5d1cqfqqnr902kj8da9s0hq6q7kqj-logseq-0.10.9/share/logseq/resources/app/electron.js:13566:42)
    at BrowserWindow.<anonymous> (/nix/store/hsb5d1cqfqqnr902kj8da9s0hq6q7kqj-logseq-0.10.9/share/logseq/resources/app/electron.js:16753:20)
    at BrowserWindow.emit (node:events:526:35)

Whereas if I control + C and Logseq is not locked up, it exits cleanly.

logseq / logseq