Bug 453280

Summary:	kded5 leaks X-Window connections: Maximum number of clients reached
Product:	[Plasma] KScreen	Reporter:	Raman Gupta <rocketraman>
Component:	kded	Assignee:	kscreen-bugs-null <kscreen-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	andkde, chemobejk, danielroschka, i.newton, ilya, jerryrwu, kdebugs, kdelibs-bugs, kishore96, max, mikiya.okuno, nate, notmart, phil.hord, ppwwyyxxc, raydude, teet.talviste
Priority:	NOR
Version:	5.24.4
Target Milestone:	---
Platform:	Manjaro
OS:	Linux
Latest Commit:	https://invent.kde.org/plasma/kscreen/commit/93cfd297506e4106a7b6e7bcc649442c5bf0f7d1	Version Fixed In:	5.24.6
Sentry Crash Report:
Attachments:	journald.log kscreen: fix XCB connection resource leak

Description Raman Gupta 2022-05-02 03:53:17 UTC

SUMMARY
I started receiving the error "Maximum number of clients reached" when trying to open new X-based programs.

Upon investigation, I saw that `kded5` was using 146 connections -- the next highest program was using 8 [1]. Restarting kded5 solved the problem.

[1] I used the script found here to identify this: https://unix.stackexchange.com/a/700637/11249


STEPS TO REPRODUCE
1. Leave desktop running for a few days/weeks, until X reports "Maximum number of clients reached" when trying to start a new window.

SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 35
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.2
Kernel Version: 5.16.20-200.fc35.x86_64 (64-bit)
Graphics Platform: X11
Processors: 32 × AMD Ryzen Threadripper 1950X 16-Core Processor
Memory: 62.7 GiB of RAM
Graphics Processor: AMD Radeon RX 590 Series

ADDITIONAL INFORMATION
It appears I'm not the only one experiencing this probem. See also: https://unix.stackexchange.com/questions/700366/kded-taking-up-x-client-connections

Comment 1 raydude 2022-05-07 23:57:17 UTC

I just upgraded my Gentoo install to the following versions and had the same issue:

Killing kded5 solved the problem and the process never returned.

If you need more information, just ask.

equery list *kde*
 * Searching for *kde* ...
[IP-] [  ] kde-apps/kde-apps-meta-21.12.3:5
[IP-] [  ] kde-apps/kdeadmin-meta-21.12.3:5
[IP-] [  ] kde-apps/kdebugsettings-21.12.3:5
[IP-] [  ] kde-apps/kdecore-meta-21.12.3:5
[IP-] [  ] kde-apps/kdeedu-data-21.12.3:5
[IP-] [  ] kde-apps/kdeedu-meta-21.12.3:5
[IP-] [  ] kde-apps/kdegames-meta-21.12.3:5
[IP-] [  ] kde-apps/kdegraphics-meta-21.12.3:5
[IP-] [  ] kde-apps/kdegraphics-mobipocket-21.12.3:5
[IP-] [  ] kde-apps/kdemultimedia-meta-21.12.3:5
[IP-] [  ] kde-apps/kdenetwork-filesharing-21.12.3:5
[IP-] [  ] kde-apps/kdenetwork-meta-21.12.3:5
[IP-] [  ] kde-apps/kdenlive-21.12.3:5
[IP-] [  ] kde-apps/kdeutils-meta-21.12.3:5
[IP-] [  ] kde-apps/ktp-kded-module-21.12.3:5
[IP-] [  ] kde-apps/libkdegames-21.12.3:5
[IP-] [  ] kde-frameworks/kdeclarative-5.92.0:5/5.92
[IP-] [  ] kde-frameworks/kded-5.92.0:5/5.92
[IP-] [  ] kde-frameworks/kdelibs4support-5.92.0:5/5.92
[IP-] [  ] kde-misc/kdeconnect-21.12.3:5
[IP-] [  ] kde-plasma/kde-cli-tools-5.24.4:5
[IP-] [  ] kde-plasma/kde-gtk-config-5.24.4:5
[IP-] [  ] kde-plasma/kdecoration-5.24.4:5
[IP-] [  ] kde-plasma/kdeplasma-addons-5.24.4-r1:5
[IP-] [  ] kde-plasma/polkit-kde-agent-5.24.4:5
[IP-] [  ] kde-plasma/xdg-desktop-portal-kde-5.24.4-r1:5
[IP-] [  ] sys-libs/libblockdev-2.25:0

Comment 2 Phil Hord 2022-05-08 00:45:53 UTC

I tracked when the leaks occur.  For me it happens when my screen is locked.  I have multiple monitors and sometimes there are issues with one of the monitors waking up.  I don't know if that's related.

Restarting kded5 does free up most of the connections. When it restarts it creates about 4 new connections.  The count remains at 4 until my PC screen locks again.  Then it gradually increases over time while locked.  

For example, today I left my desk from 2:50 until about 5:15.  I left this script running to record changes in the number of kded5 X11 connections while I was gone.  At 5:19 I ran "kded5 --replace & disown" in another terminal session.

    prev=0 ; while sleep 5 ; do
    count=$(sudo ss -x src "*/tmp/.X11-unix/*" | grep -Eo "[0-9]+\\s*$" | while read port ; 
    do sudo ss -p -x | grep -w $port | grep -v X11-unix ; 
    done | grep -Eo '".+"' | grep -c kded5) ;
    test $prev -eq $count || echo $count $(date) ; prev=$count; done

    4 Sat 07 May 2022 12:07:47 PM PDT
    8 Sat 07 May 2022 03:09:19 PM PDT
    11 Sat 07 May 2022 03:19:27 PM PDT
    12 Sat 07 May 2022 03:19:34 PM PDT
    16 Sat 07 May 2022 03:29:37 PM PDT
    20 Sat 07 May 2022 03:39:50 PM PDT
    24 Sat 07 May 2022 03:57:08 PM PDT
    28 Sat 07 May 2022 04:12:36 PM PDT
    32 Sat 07 May 2022 04:22:46 PM PDT
    34 Sat 07 May 2022 04:32:52 PM PDT
    36 Sat 07 May 2022 04:33:00 PM PDT
    40 Sat 07 May 2022 04:51:13 PM PDT
    42 Sat 07 May 2022 05:01:20 PM PDT
    44 Sat 07 May 2022 05:01:29 PM PDT
    48 Sat 07 May 2022 05:12:32 PM PDT
    3 Sat 07 May 2022 05:19:48 PM PDT
    4 Sat 07 May 2022 05:19:55 PM PDT

Comment 3 Phil Hord 2022-05-08 16:58:41 UTC

Interesting that it seemed to leak 2 connections at 10 minute intervals.  Last night it leaked 4 connections at 10 minute intervals. Again, it only happened when the screen was locked.

3 Sat 07 May 2022 05:19:48 PM PDT
4 Sat 07 May 2022 05:19:55 PM PDT
8 Sat 07 May 2022 07:28:39 PM PDT
12 Sat 07 May 2022 07:38:47 PM PDT
16 Sat 07 May 2022 07:48:58 PM PDT
20 Sat 07 May 2022 07:59:04 PM PDT
23 Sat 07 May 2022 08:09:12 PM PDT
24 Sat 07 May 2022 08:09:20 PM PDT
28 Sat 07 May 2022 08:19:23 PM PDT
32 Sat 07 May 2022 08:35:37 PM PDT
34 Sat 07 May 2022 08:45:44 PM PDT
36 Sat 07 May 2022 08:45:52 PM PDT
38 Sat 07 May 2022 08:56:00 PM PDT
40 Sat 07 May 2022 08:56:08 PM PDT
42 Sat 07 May 2022 09:06:10 PM PDT
44 Sat 07 May 2022 09:06:18 PM PDT
46 Sat 07 May 2022 09:16:20 PM PDT
48 Sat 07 May 2022 09:16:28 PM PDT
52 Sat 07 May 2022 09:26:39 PM PDT
54 Sat 07 May 2022 09:36:44 PM PDT
56 Sat 07 May 2022 09:36:52 PM PDT
60 Sat 07 May 2022 09:46:59 PM PDT
61 Sat 07 May 2022 09:47:26 PM PDT
65 Sat 07 May 2022 09:47:45 PM PDT
69 Sat 07 May 2022 09:57:55 PM PDT
73 Sat 07 May 2022 10:08:01 PM PDT
77 Sat 07 May 2022 10:18:13 PM PDT
79 Sat 07 May 2022 10:28:16 PM PDT
81 Sat 07 May 2022 10:28:25 PM PDT
84 Sat 07 May 2022 10:38:26 PM PDT
85 Sat 07 May 2022 10:38:36 PM PDT
89 Sat 07 May 2022 10:48:38 PM PDT
93 Sat 07 May 2022 10:58:47 PM PDT
97 Sat 07 May 2022 11:09:02 PM PDT
101 Sat 07 May 2022 11:19:07 PM PDT
105 Sat 07 May 2022 11:29:18 PM PDT
109 Sat 07 May 2022 11:39:27 PM PDT
113 Sat 07 May 2022 11:49:35 PM PDT
117 Sat 07 May 2022 11:59:49 PM PDT
121 Sun 08 May 2022 12:09:55 AM PDT
125 Sun 08 May 2022 12:20:05 AM PDT
127 Sun 08 May 2022 12:30:10 AM PDT
129 Sun 08 May 2022 12:30:21 AM PDT
133 Sun 08 May 2022 12:40:24 AM PDT
137 Sun 08 May 2022 12:50:34 AM PDT
140 Sun 08 May 2022 01:00:40 AM PDT
141 Sun 08 May 2022 01:00:52 AM PDT
145 Sun 08 May 2022 01:10:54 AM PDT
149 Sun 08 May 2022 01:21:03 AM PDT
151 Sun 08 May 2022 01:31:07 AM PDT
153 Sun 08 May 2022 01:31:19 AM PDT
155 Sun 08 May 2022 01:41:18 AM PDT
157 Sun 08 May 2022 01:41:30 AM PDT
161 Sun 08 May 2022 01:51:36 AM PDT
164 Sun 08 May 2022 02:01:38 AM PDT
165 Sun 08 May 2022 02:01:50 AM PDT
168 Sun 08 May 2022 02:11:48 AM PDT
169 Sun 08 May 2022 02:12:01 AM PDT
173 Sun 08 May 2022 02:22:06 AM PDT
177 Sun 08 May 2022 02:32:16 AM PDT
180 Sun 08 May 2022 02:42:20 AM PDT
181 Sun 08 May 2022 02:42:33 AM PDT
185 Sun 08 May 2022 02:52:30 AM PDT
189 Sun 08 May 2022 03:02:48 AM PDT
192 Sun 08 May 2022 03:12:49 AM PDT

Comment 4 Raman Gupta 2022-05-10 13:21:09 UTC

Just FYI -- my leak *might* also be related to the lock screen and/or monitors sleeping, but the behavior on my machine seems to be different than with Phil Hord -- using the same script as in comment #2, with the computer locked overnight, 5 connections were leaked, but only when the monitors woke up / computer was unlocked at 08:44:13 -- none were leaked while the monitors were sleeping / lock screen was active:

Computer went to sleep at approximately 6:30 pm, woke up at 8:44 am:

124 Mon May 9 05:13:53 PM EDT 2022
129 Tue May 10 08:44:13 AM EDT 2022

Comment 5 Raman Gupta 2022-05-11 12:50:41 UTC

I believe the issue is more related to monitors going into a power-saving mode rather than the screen locking -- 5 connections were leaked this morning when my monitors were woken up, but before the lock screen activated.

Comment 6 Teet Talviste 2022-05-22 06:59:09 UTC

I use dell u3415w monitor with internal kvm switch and 2 kde computers, kded5 leaks connections every time i switch. Turning the monitor off and on will also produce an increase in connections (i guess this would be the easiest method to reproduce the behavior).

Comment 7 Mikiya Okuno 2022-05-23 01:50:30 UTC

I also encounter the same problem. By turning off, and on the monitor display, 6 sessions leak. I check the session by the following command as in the link in the Raman Gupta's comment:

$ sudo ss -x src "*/tmp/.X11-unix/*" | grep -Eo "[0-9]+\s*$" | while read port; do sudo ss -p -x | grep -w $port | grep -v X11-unix ; done | grep -Eo '".+"' | sort | uniq -c | sort -rn
    106 "kded5"
     14 "VirtualBoxVM"
      6 "dbus-launch"
      4 "konsole"
      3 "slack"
      2 "kwin_x11"
... skip ...

Disconnecting/connecting an HDMI cable also leak 6 sessions. I connect an HDMI cable directly to my video card.

The problem is really irritating. I have to restart my machine every time when the session is running out. Since the maximum number of X11 sessions available is 256, the session runs out by 42 monitor power cycles at maximum. Other applications also open X11 sessions, so it runs out even earlier.

Comment 8 kdebugs 2022-05-23 05:52:22 UTC

(In reply to Mikiya Okuno from comment #7)
> The problem is really irritating. I have to restart my machine every time
> when the session is running out. Since the maximum number of X11 sessions
> available is 256, the session runs out by 42 monitor power cycles at
> maximum. Other applications also open X11 sessions, so it runs out even
> earlier.

Irritating indeed, but you can avoid having to restart the whole computer with just restarting kded5
Personally I kill the process and start kded5 with kstart5, but I'm not sure if this is the "correct" method or not
but it seemingly works without any negative effects

Comment 9 Ian Newton 2022-05-26 09:47:38 UTC

Created attachment 149228 [details]
journald.log

Comment 10 Ian Newton 2022-05-26 09:56:07 UTC

For my setup with an external screen connected by USB C. If  the screen is connected but not enabled there is repeated detection cycles as in "kscreen_backend_launcher	kscreen.xrandr: Emitting configChanged()" which result in added kded5 processes mounting to 140 or more. When the screen is used in the screen configuration (extended desktop) the cycling stops. See journald.log above

Comment 11 Raman Gupta 2022-05-26 13:03:40 UTC

(In reply to kdebugs from comment #8)
> (In reply to Mikiya Okuno from comment #7)
> > The problem is really irritating. I have to restart my machine every time
> > when the session is running out. Since the maximum number of X11 sessions
> > available is 256, the session runs out by 42 monitor power cycles at
> > maximum. Other applications also open X11 sessions, so it runs out even
> > earlier.
> 
> Irritating indeed, but you can avoid having to restart the whole computer
> with just restarting kded5
> Personally I kill the process and start kded5 with kstart5, but I'm not sure
> if this is the "correct" method or not
> but it seemingly works without any negative effects

On Fedora, kded appears to run via systemd user unit, so the "right" way to do it appears to be :

systemd --user restart plasma-kded

Comment 12 Stefan Becker 2022-05-26 16:17:14 UTC

I was just going to open a bug report for this. I agree this is highly annoying and it took a while to track it down to kded5. Thanks Raman for the systemctl tip for Fedora. Manually killing kded5 seems sometimes to have negative side-effects....

I can confirm that on one of the machines, where I encountered this issue, it is related to output switching. The machine is connected via HDMI to an AV receiver. Simply switching the amplifier off or on increases the amount of X11 client connections kded5 increases by various amounts (+2 to +6 connections).

Another bit of information: disabling the KScreen background service, i.e. the service that detects and propagates output changes, also "fixes" the issue as kded5 no longer is made aware of those changes.

I'm not aware ever seeing this error message before it started to appear a few months back. That probably indicates that some change to Plasma 5.24.x introduced the issue.

Comment 13 Raman Gupta 2022-05-26 16:25:53 UTC

(In reply to Raman Gupta from comment #11)
> On Fedora, kded appears to run via systemd user unit, so the "right" way to
> do it appears to be :
> 
> systemd --user restart plasma-kded

Oops, that should be:

systemctl --user restart plasma-kded

Comment 14 Phil Hord 2022-05-26 17:58:52 UTC

I have reinstalled KDE Neon on a new laptop. I have made minimal configuration changes to the desktop.  

I now see that the leak occurs whenever my desktop geometry changes.  Without an external monitor attached, two kded5->X11 client connections are leaked every time I change the display resolution on the laptop screen.

This was exacerbated before by some instability in my external monitor connection which apparently caused it to disconnect every 10 minutes while on the lockscreen.  I don't have that same problem on this new laptop, so now my leaks occur only when I connect or disconnect from my monitors manually.

Operating System: KDE neon 5.24
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4
Kernel Version: 5.13.0-44-generic (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-10610U CPU @ 1.80GHz
Memory: 15.3 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics

Comment 15 Phil Hord 2022-05-26 18:15:50 UTC

If I rotate my screen 180 degrees, I also see the memory leak.  This does not involve any desktop geometry change; no windows get moved or resized, and no widgets are redrawn.  Perhaps this absolves some desktop widget of causing the issue.

If I switch to a console tty (Ctrl+Alt+F3) and then back to the desktop, no leak occurs.

It does seem to correlate to kscreen configChanged, as Ian Newton already pointed out.

Following is from my syslog when I rotate the screen and then subsequently see the leaks:

kscreen_backend_launcher[1407]: kscreen.xrandr: XRandR::setConfig
kscreen_backend_launcher[1407]: kscreen.xrandr: Requested screen size is QSize(2560, 1440)
kscreen_backend_launcher[1407]: kscreen.xrandr: Needed CRTCs:  1
kscreen_backend_launcher[1407]: kscreen.xrandr: Actions to perform: #012 #011Primary Output: false
kscreen_backend_launcher[1407]: kscreen.xrandr: #011Change Screen Size: false
kscreen_backend_launcher[1407]: kscreen.xrandr: #011Disable outputs: false
kscreen_backend_launcher[1407]: kscreen.xrandr: #011Change outputs: true
kscreen_backend_launcher[1407]: kscreen.xrandr: #011#011 (66)
kscreen_backend_launcher[1407]: kscreen.xrandr: #011Enable outputs: false
kscreen_backend_launcher[1407]: kscreen.xrandr: RRSetCrtcConfig (change output) #012 #011Output: 66 ( "eDP-1" ) #012 #011CRTC: 63 #012 #011Pos: QPoint(0,0) #012 #011Mode: KScreen::Mode(Id: "71" , Size: QSize(2560, 1440) @ 59.9977 ) Preferred: "71" #012 #011Rotation: KScreen::Output::None
kscreen_backend_launcher[1407]: kscreen.xrandr: XRandRCrtc  63  m_timestamp update  65021240  =>  65037306
kscreen_backend_launcher[1407]: kscreen.xrandr: #011Result:  0  timestamp:  65037306
kscreen_backend_launcher[1407]: kscreen.xrandr: XRandROutput 66 update #012 #011m_connected: 0 #012 #011m_crtc XRandRCrtc(0x558a2aeab650) #012 #011CRTC: 63 #012 #011MODE: 71 #012 #011Connection: 0 #012 #011Primary: true
kscreen_backend_launcher[1407]: kscreen.xrandr: XRandR::setConfig done!
kscreen_backend_launcher[1407]: kscreen.xcb.helper: RRNotify_CrtcChange
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011Timestamp:  65021240
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011CRTC:  63
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011Mode:  71
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011Rotation:  "Rotate_0"
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011Geometry:  0 0 2560 1440
kscreen_backend_launcher[1407]: kscreen.xcb.helper: RRScreenChangeNotify
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011Timestamp:  65021240
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011Config_timestamp:  63769310
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011Window: 58720261
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011Root: 2004
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011Rotation:  "Rotate_0"
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011Size ID: 0
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011Size:  2560 1440
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011SizeMM:  677 381
kscreen_backend_launcher[1407]: kscreen.xcb.helper: RRNotify_CrtcChange
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011Timestamp:  65021240
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011CRTC:  63
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011Mode:  71
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011Rotation:  "Rotate_0"
kscreen_backend_launcher[1407]: kscreen.xcb.helper: #011Geometry:  0 0 2560 1440
kscreen_backend_launcher[1407]: kscreen.xrandr: XRandRCrtc  63  m_configTimestamp update 64782251  =>  65021240
kscreen_backend_launcher[1407]: kscreen.xrandr: Emitting configChanged()

Comment 16 Stefan Becker 2022-05-29 15:52:13 UTC

Created attachment 149318 [details]
kscreen: fix XCB connection resource leak

After digging through the source code and running kded5 under ltrace

    $ ltrace -e xcb_connect+xcb_connect_to_display_with_auth_info+xcb_connect_to_fd+xcb_disconnect-@libxcb.so.1 kded5

I was able to track down the resource leak. This error is mis-attributed to "kded", the culprit is "kscreen". More specifically the problem was introduced by this git commit:

    commit 09b988e6628093e7d4c8b92cd8a0a1fe2da2f77e
    Author: Marco Martin <notmart@gmail.com>
    Date:   Fri Mar 4 09:05:19 2022 +0000
    
        X11: align touchscreen to internal display
        
        On Wayland is the compositor itself that keeps the touchscreen coordinates mapped to the size and position of the internal screen, also keeping rotation into account.
        on X11, needs to be done via XInput, do it when KScreen actually applies a configuration.
        
        BUG: 415683

XOpenDisplay() internally calls xcb_connect(), which allocates a new XCB connection. Therefore you need to call XCloseDisplay() again to release the connection. This is what the attached patch does. With it the problem can no longer be reproduced.

There may be other or better ways to fix this, e.g.
* determine X Display from the XCB connection retrieved from QX11Info
* use XCB calls with XCB connection instead of X calls that require X Display
but I was unable to determine that based on API documentation.

Comment 17 Stefan Becker 2022-05-29 15:57:32 UTC

Forgot to mention: kded doesn't know anything about X11, there are no references in the source code

But KScreen has a piece of code running in kded5 process context: the kscreen kded plugin.

Comment 18 Bug Janitor Service 2022-05-29 20:36:44 UTC

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kscreen/-/merge_requests/102

Comment 19 Stefan Becker 2022-05-30 07:33:17 UTC

Git commit 0270a49328aa70b14dd08e2ed5a425ca3f8e4fd5 by Stefan Becker.
Committed on 30/05/2022 at 04:23.
Pushed by davidedmundson into branch 'master'.

X11: fix kded xcb resource leak

This fixes commit 579358f501ae978aa527a25eb3ef9dd42557db46

XOpenDisplay() internally calls xcb_connect(), creating a new XCB client
connection. This means that on every KScreen configuration change event
the kded5 process creates a new connection until XCB runs into the hard
limit of 256 of clients, leading to the dreaded "Maximum number of
clients reached" error.

Re-use the display from QX11Info instead of calling XOpenDisplay().

M  +8    -9    kded/daemon.cpp

https://invent.kde.org/plasma/kscreen/commit/0270a49328aa70b14dd08e2ed5a425ca3f8e4fd5

Comment 20 David Edmundson 2022-05-30 07:57:42 UTC

Git commit d7e60e197bdcdf645197881d3f2e4da0cf4557f4 by David Edmundson, on behalf of Stefan Becker.
Committed on 30/05/2022 at 07:57.
Pushed by davidedmundson into branch 'Plasma/5.25'.

X11: fix kded xcb resource leak

This fixes commit 579358f501ae978aa527a25eb3ef9dd42557db46

XOpenDisplay() internally calls xcb_connect(), creating a new XCB client
connection. This means that on every KScreen configuration change event
the kded5 process creates a new connection until XCB runs into the hard
limit of 256 of clients, leading to the dreaded "Maximum number of
clients reached" error.

Re-use the display from QX11Info instead of calling XOpenDisplay().


(cherry picked from commit 0270a49328aa70b14dd08e2ed5a425ca3f8e4fd5)

M  +8    -9    kded/daemon.cpp

https://invent.kde.org/plasma/kscreen/commit/d7e60e197bdcdf645197881d3f2e4da0cf4557f4

Comment 21 David Edmundson 2022-05-30 07:58:24 UTC

Git commit 93cfd297506e4106a7b6e7bcc649442c5bf0f7d1 by David Edmundson, on behalf of Stefan Becker.
Committed on 30/05/2022 at 07:58.
Pushed by davidedmundson into branch 'Plasma/5.24'.

X11: fix kded xcb resource leak

This fixes commit 579358f501ae978aa527a25eb3ef9dd42557db46

XOpenDisplay() internally calls xcb_connect(), creating a new XCB client
connection. This means that on every KScreen configuration change event
the kded5 process creates a new connection until XCB runs into the hard
limit of 256 of clients, leading to the dreaded "Maximum number of
clients reached" error.

Re-use the display from QX11Info instead of calling XOpenDisplay().


(cherry picked from commit 0270a49328aa70b14dd08e2ed5a425ca3f8e4fd5)

M  +8    -9    kded/daemon.cpp

https://invent.kde.org/plasma/kscreen/commit/93cfd297506e4106a7b6e7bcc649442c5bf0f7d1

Comment 22 Stefan Becker 2022-06-03 13:07:02 UTC

FYI: this is fixed on Fedora 36 with kscreen-1:5.24.5-2.fc36 (https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7b84908ae)

Comment 23 Nicolas Fella 2022-06-08 07:49:08 UTC

*** Bug 455004 has been marked as a duplicate of this bug. ***