desktop [Bug]: Nextcloud desktop client (macOS) becomes unresponsive at 100% CPU

⚠️ Before submitting, please verify the following: ⚠️

[x] This is a bug, not a question or a configuration issue.
[x] This issue is not already reported on Github (I've searched it).
[x] Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
[x] I agree to follow Nextcloud's Code of Conduct

Bug description

The desktop client starts syncing and then becomes unresponsive quickly. If I pause the sync right after the client starts then it does not crash.

Steps to reproduce

Unknown

Expected behavior

Desktop client should sync the files and stay responsive.

Which files are affected by this bug

I did not manage to deterministically pinpoint it to a specific file.

Operating system

macOS

Which version of the operating system you are running.

macOS Sonoma 14.7 (23H124)

Package

Official macOS 12+ universal pkg

Nextcloud Server version

29.0.7

Nextcloud Desktop Client version

3.14.1

Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 3.4.2 to 3.4.4)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

Are you using an external user-backend?

[x] Default internal user-backend
[ ] LDAP/ Active Directory
[ ] SSO - SAML
[ ] Other

Nextcloud Server logs

Additional info

The server is running Ubuntu 22.04, but the problem was already present on 20.04.
There is 48GB of free space on the server and more than 150GB on the client.
I ran occ files:scan --all and occ maintenance:repair.
There are no configuration warnings.
I tried to pinpoint the issue to specific directories or files but did not reach any conclusive results. I tried both excluding directories via the ignore list and manually removing and re-adding them on both the client and server. At one point or another, the client always becomes unresponsive.
I've had this issue across multiple client and server versions. Unfortunately, I don't remember when it started on the client, but on the server, it has been present since before the "Hub" versions were introduced.
I tried removing the ".sync" files as suggested in this comment, but with no success.
I tried downgrading to several versions, including 3.4.2, but all showed the same symptoms.
An excerpt of the server logs is attached. Happy to provide more if needed. Also happy to provide the client logs, but I wasn't sure if they potentially contain any sensitive information.

Oct 21 '24 17:10 danrex

If you are using the Mac OS VFS client, you might be experiencing the same issue decribed here: #7326

Oct 21 '24 20:10 marcotrevisan

If you are using the Mac OS VFS client, you might be experiencing the same issue decribed here: #7326

Thanks @marcotrevisan. I’m using the 'classic' client. I reviewed the issue for any clues beforehand, but unfortunately, it doesn’t seem related.

Oct 22 '24 07:10 danrex

Same problem here on 15.0.1 (24A348) with both versions of the client (VFS or not)

Oct 24 '24 06:10 philippgerard

I have the same issue. I have tried using older versions that used to work but the apps still becomes unresponsive with 100% CPU usage.

Nov 05 '24 02:11 MenacingMight

I have the same problem. becomes unresponsive with 100% CPU. We urgently need a solution here....

Cheers

Nov 11 '24 12:11 rondoron

I don't know whether it is relevant to this, but for me on Ubuntu 24.04, the deb version becomes unresponsive and starts eating more and more RAM until it gets OOM-killed. The behavior is the same on both the latest 3.14.3 version as well as 3.11 from the Ubuntu repos. Apparently, there are some files that trigger it to do so but I see no logic whatsoever, these are just random files which sync perfectly well on my other laptop with the same Ubuntu 24.04 system. I tried deleting configuration files, deleting the sync file, deleting the entire folder and syncing it from scratch, but it all didn't help much. The AppImage version just randomly dies. The flathub version so far seems to stay put. I don't know whether this bug has anything to do with Nextcloud or I somehow managed to bork my Ubuntu.

Nov 13 '24 09:11 undefiened

I don't know whether it is relevant to this, but for me on Ubuntu 24.04, the deb version becomes unresponsive and starts eating more and more RAM until it gets OOM-killed. The behavior is the same on both the latest 3.14.3 version as well as 3.11 from the Ubuntu repos. Apparently, there are some files that trigger it to do so but I see no logic whatsoever, these are just random files which sync perfectly well on my other laptop with the same Ubuntu 24.04 system. I tried deleting configuration files, deleting the sync file, deleting the entire folder and syncing it from scratch, but it all didn't help much. The AppImage version just randomly dies. The flathub version so far seems to stay put. I don't know whether this bug has anything to do with Nextcloud or I somehow managed to bork my Ubuntu.

Maybe related to the issue that was shared above (if you use the VFS client)?

Nov 13 '24 11:11 danrex

Maybe related to the issue that was shared above (if you use the VFS client)?

No, I don't think VFS support is implemented for Linux.

Nov 13 '24 16:11 undefiened

My Nextcloud desktop client also eats 100% CPU and is totally unresponsive, version 3.14.3, AppImage, Fedora 41 (Linux).

So probably not simply @undefiened having borked their Ubuntu...

Nov 16 '24 20:11 bovender

I ran strace on my Nextcloud client. I found out that the client tried to descent through an Directory symlink. After i removed the symlink, the Client behaved normally again. Could someone else check if their problem could stem from this? Previous versions Ignored the Directory since it was an symlink.

Nov 18 '24 10:11 stop5

I ran strace on my Nextcloud client.

@stop5 bear with me, I'll report back (note to self: finally stop forgetting about strace when debugging stuff...)

BTW, I was called away from my laptop this morning while the Nextcloud client was at 100% CPU (I had htop running on the side) and when I returned ~1 hour later, Nextcloud was idling.

Furthermore, right now I have the strace nexcloud... running in a terminal and the process is idling, too. Need to find out what exactly triggers the high CPU usage which I've seen on my machine several days in a row now.

Nov 18 '24 14:11 bovender

I also invested some more time to dig in deeper and it seems the problem might be related to a connection setting. I had "Upload Bandwidth" set to "Limit automatically". I changed that to "No limit" and the client is working fine for the first time in months. Fingers are still crossed though 🤞.

Nov 20 '24 17:11 danrex

I'm experiencing the same problem in opensuse Tumbleweed; it started with version 3.14.2 and is always present in 3.14.3 I installed today. I have "no limit" bandwidth selected, but alas! 100% CPU usage while syncing.

Nov 20 '24 21:11 verga

Hey, I have the same issue on Linux as well. Some performance tracing shows that the CPU usage comes from constantly reallocating memory. Tracing that backwards leads to the following code: https://github.com/nextcloud/desktop/blob/907b07cc0968b515e585d9453d888bec0e91942c/src/libsync/syncengine.cpp#L1219-L1222 Here it becomes obvious that the string first is reallocated on every loop iteration and as _localDiscoveryPaths can easily contain thousands of paths this becomes very slow. For me it didn't finish within 30 minutes.

The code was introduced in #7291 and reverting this commit on the latest stable release (3.15) fixes the issue for me.

Nov 29 '24 14:11 Diff-fusion

Still the same with 3.15.1.

I've "killed" the client now in order to give my laptop's fans a rest. Hoping for a fix.

Dec 15 '24 16:12 bovender

I'm experiencing the same problem in opensuse Tumbleweed; it started with version 3.14.2 and is always present in 3.14.3 I installed today. I have "no limit" bandwidth selected, but alas! 100% CPU usage while syncing.

I'd like to confirm this find. To remove the limit remove entries below

[BWLimit]
downloadLimit=80
uploadLimit=10
useDownloadLimit=-1
useUploadLimit=-1

from config file: $HOME/Library/Preferences/Nextcloud/nextcloud.cfg

Dec 18 '24 11:12 haloween

The BWLimit does not change anything for me (I'm on Linux Opensuse) Still the same behavior with the last client 3.15.2

Dec 18 '24 17:12 verga

Hey, I have the same issue on Linux as well. Some performance tracing shows that the CPU usage comes from constantly reallocating memory. Tracing that backwards leads to the following code:

desktop/src/libsync/syncengine.cpp

Lines 1219 to 1222 in 907b07c

const auto allPaths = std::accumulate(_localDiscoveryPaths.begin(), _localDiscoveryPaths.end(), QString{}, [] (auto first, auto second) -> QString { first += ", " + second; return first; });

Here it becomes obvious that the string first is reallocated on every loop iteration and as _localDiscoveryPaths can easily contain thousands of paths this becomes very slow. For me it didn't finish within 30 minutes. The code was introduced in #7291 and reverting this commit on the latest stable release (3.15) fixes the issue for me.

I also expirienced the 100% CPU used issue on an arch linux system using version 3.15.2. Using perf I could trace the cause to the memory allocation of building the allPaths QString.

Simply deleting the two statements solved the issue for me.

diff --git a/src/libsync/syncengine.cpp b/src/libsync/syncengine.cpp
index 368d0f8c8..1df36bdf4 100644
--- a/src/libsync/syncengine.cpp
+++ b/src/libsync/syncengine.cpp
@@ -1216,13 +1216,6 @@ void SyncEngine::setLocalDiscoveryOptions(LocalDiscoveryStyle style, std::set<QS
     _localDiscoveryStyle = style;
     _localDiscoveryPaths = std::move(paths);
 
-    const auto allPaths = std::accumulate(_localDiscoveryPaths.begin(), _localDiscoveryPaths.end(), QString{}, [] (auto first, auto second) -> QString {
-                              first += ", " + second;
-                              return first;
-    });
-
-    qCInfo(lcEngine()) << "paths to discover locally" << allPaths;
-
     // Normalize to make sure that no path is a contained in another.
     // Note: for simplicity, this code consider anything less than '/' as a path separator, so for
     // example, this will remove "foo.bar" if "foo" is in the list. This will mean we might have

Dec 30 '24 11:12 fischerling

Hello,

the client was enhanced significantly since the opening of this ticket. You can help us with a retest. If you are still encountering issues, please get back to us

Sep 12 '25 01:09 Rello