Hi,

I stumbled upon some kind of two-fold bug. I'll begin with the second part
(which could as well be a bug on its own) because this is the most noticeable
part.
When kioslave5 is called with an empty string as third argument (<klauncher-
socket> as indicated in '--help' message), it loops infinitely resulting in
100% CPU utilization.
I can tell from inspecting with a debugger, that it keeps calling close()
repeatedly.
/proc/<pidof-kioslave>/cmdline shows two consecutive null bytes where the third
argument would be.
The problem can be seen for example when using ktorrent and connecting to any
http(s) tracker (like the torrents from cdimage.debian.org) or trying to open
an http(s) url pointing to a torrent file.
It can also be seen when using 'Save as' in Kate, but now with the thumbnail.so
module instead of kio_http.so, again with an empty string as 3rd arg.

This leads me to part one of this bug: Why is kioslave5 called with an empty
string? I cannot recall updating ktorrent or kate (or even kio) prior to this
bug showing up.
I'm not even sure if this is kio's fault or some other lib in between. But
wouldn't it be the responsibility of kioslave5 (or its modules) to at least
check for nonsense arguments and return with an error instead of looping
infinitely?

noticeable
(<klauncher-
in


Hello.

It looks like:

Ktorrent raises the nofile soft limit to hard limit and spawns http kio
helpers.

Because of changes done in the #1070322 kioslave5 process tries to close
1_073_741_813 file descriptors (in my case)

Then ktorrent kills these helpers on timeout (because more than 10 minutes
is required for the loop) and shows connection error for trackers.

So the solution (or workaround) is to lower the nofile hard limit.
Just reduced it to 8192:8192 for ktorrent (and kate as well), and
suddenly it works again.

But should this be the final solution? Does kioslave really need to (try
to) close that number of fds? Are they even open?

Hello,
if the limits are that high to cause closing them all take too much time,
maybe the patch should use the close_range call instead of individual close calls?

I found examples in kde [2] [3], which uses the close_range call.
Another one in [4] in salsa.

Kind regards,
Bernhard

[1] https://salsa.debian.org/qt-kde-team/kde/kio/-/commit/4c4f9f3605d53b48588a79c1883475cc33f6e486
[2] https://invent.kde.org/frameworks/kinit/-/merge_requests/15/diffs
[3] https://invent.kde.org/frameworks/kdesu/-/merge_requests/17/diffs
[4] https://salsa.debian.org/clint/fakeroot/-/merge_requests/30/diffs