[Bug]: Automatic upload bandwidth hangs client

[tokudan]

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

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

Bug description

I have a big folder (~550 GB) completely synced. Adding some more gigabytes to it, causes the client to freeze indefinitely (>5 minutes) and become unresponsive.

Steps to reproduce

1. Upload bandwith in Network tab is set to "Automatisch begrenzen" (~limit automatically)
2. Add ~10 GB in a couple bigger files (around 25-100 MB) to a huge folder (~550 GB) that the client syncs (unsure if the client needs to be running at this time or needs to be started after)
3. The client freezes.

Expected behavior

The client should finish the upload and not freeze.

Which files are affected by this bug

no specific file name known

Operating system

Linux

Which version of the operating system you are running.

NixOS unstable

Package

Distro package manager

Nextcloud Server version

Storage Share 27.1.5

Nextcloud Desktop Client version

3.11.0

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?

• Default internal user-backend
• LDAP/ Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

No response

Additional info

Running the client in strace just shows mostly useless information and the output suddenly stops. The last messages are all clock_gettime before the output stops when the client freezes.

I got a stacktrace by sending an ABRT signal:

Core was generated by `nextcloud'.
Program terminated with signal SIGABRT, Aborted.

warning: Section `.reg-xstate/15023' in core file too small.
#0  0x00007fa1bed0ad41 in QHttpMultiPartIODevice::readData(char*, long long) () from /nix/store/jiprinddjxbksh18gamf3c5yk1d7pbrr-qtbase-5.15.11/lib/libQt5Network.so.5
[Current thread is 1 (Thread 0x7fa1b477fcc0 (LWP 15023))]
(gdb) bt
#0  0x00007fa1bed0ad41 in QHttpMultiPartIODevice::readData(char*, long long) () from /nix/store/jiprinddjxbksh18gamf3c5yk1d7pbrr-qtbase-5.15.11/lib/libQt5Network.so.5
#1  0x00007fa1bd64157f in QIODevicePrivate::read(char*, long long, bool) () from /nix/store/jiprinddjxbksh18gamf3c5yk1d7pbrr-qtbase-5.15.11/lib/libQt5Core.so.5
#2  0x00007fa1bd6476bc in QNonContiguousByteDeviceIoDeviceImpl::readPointer(long long, long long&) () from /nix/store/jiprinddjxbksh18gamf3c5yk1d7pbrr-qtbase-5.15.11/lib/libQt5Core.so.5
#3  0x00007fa1bed25c87 in QNetworkReplyHttpImplPrivate::wantUploadDataSlot(long long) () from /nix/store/jiprinddjxbksh18gamf3c5yk1d7pbrr-qtbase-5.15.11/lib/libQt5Network.so.5
#4  0x00007fa1bd73dba0 in QObject::event(QEvent*) () from /nix/store/jiprinddjxbksh18gamf3c5yk1d7pbrr-qtbase-5.15.11/lib/libQt5Core.so.5
#5  0x00007fa1be61e03e in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /nix/store/jiprinddjxbksh18gamf3c5yk1d7pbrr-qtbase-5.15.11/lib/libQt5Widgets.so.5
#6  0x00007fa1bd712058 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /nix/store/jiprinddjxbksh18gamf3c5yk1d7pbrr-qtbase-5.15.11/lib/libQt5Core.so.5
#7  0x00007fa1bd715091 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /nix/store/jiprinddjxbksh18gamf3c5yk1d7pbrr-qtbase-5.15.11/lib/libQt5Core.so.5
#8  0x00007fa1bd76a413 in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () from /nix/store/jiprinddjxbksh18gamf3c5yk1d7pbrr-qtbase-5.15.11/lib/libQt5Core.so.5
#9  0x00007fa1bdae50d7 in g_main_dispatch () from /nix/store/2if9iy5cy0bicwafllpa2aiq30v26app-glib-2.78.1/lib/libglib-2.0.so.0
#10 0x00007fa1bdae7ff7 in g_main_context_iterate_unlocked.constprop () from /nix/store/2if9iy5cy0bicwafllpa2aiq30v26app-glib-2.78.1/lib/libglib-2.0.so.0
#11 0x00007fa1bdae85cc in g_main_context_iteration () from /nix/store/2if9iy5cy0bicwafllpa2aiq30v26app-glib-2.78.1/lib/libglib-2.0.so.0
#12 0x00007fa1bd769bf6 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /nix/store/jiprinddjxbksh18gamf3c5yk1d7pbrr-qtbase-5.15.11/lib/libQt5Core.so.5
#13 0x00007fa1bd710a53 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /nix/store/jiprinddjxbksh18gamf3c5yk1d7pbrr-qtbase-5.15.11/lib/libQt5Core.so.5
#14 0x00007fa1bd718f56 in QCoreApplication::exec() () from /nix/store/jiprinddjxbksh18gamf3c5yk1d7pbrr-qtbase-5.15.11/lib/libQt5Core.so.5
#15 0x000055c18cfbdeef in main ()

I was able to work around the issue by setting a specific upload speed limit (~512 kB/s), which leads me to believe that the client may try to build a huge upload package if set to automatic, that causes the freeze.

[joshtrichards]

Sounds similar to #6180 if setting an explicit upload limit fixes it. Does setting "no limit" (but not "auto") similarly fix it for you?

[tokudan]

I'm running a test with "no limit" for the upload speed and it does not seem to hang, so I assume it's going to work.
#6180 looks pretty similar, so I'm going to assume this is a duplicate.

[Nowaker]

My Nextcloud client on Mac did hang after upload when upload speed was set to "Limit automatically". Changing to "Unlimited" helped.

[ftoledo]

I can confirm this bug with AppImage on Debian Linux with client 3.12.0

[Sabering1]

same here

[ibizaman]

Confirmed here too. This issue was plaguing me for such a long time. It seems also that this solves the issue where Nextcloud Desktop was hogging the CPU when trying to upload a lot of small files (like .git repos).

By setting a limit, this is now what the network bandwidth looks like:

I would say looking at the pattern that indeed it's preparing some package then sending it.

Similarly, now downloading a lot of small files work too: