I don't know if it's relevant but the session is using X11 and I run pipewire for audio.

Do you by any chance have an NVIDIA GPU and if so is nvidia-settings installed and in use?

Yes I have an nVidia GPU w/ the nvidia arch package installed. But I do not believe nvidia-settings is installed.

I've also used ARandR to automate applying display setups because Plasma always gets confused when a display is turned on/off.

I'm wondering if there's an issue with memory leaking with an external source (i.e. not KScreen) changed display settings. We have another report of this when nvidia-settings changes it.

If you disable ARandR, does the issue stop happening?

(In reply to Nate Graham from comment #5)
> I'm wondering if there's an issue with memory leaking with an external
> source (i.e. not KScreen) changed display settings. We have another report
> of this when nvidia-settings changes it.
> 
> If you disable ARandR, does the issue stop happening?

You may misunderstand what ARandR does. It just generates scripts based on your current display config that can then be run to apply xrandr settings to apply those same settings again. It's not a service, there's nothing running and nothing to disable. I just occasionally need to run the scripts made with it to automate correcting the display configuration because it messes up every time a display device is added/removed.

(In reply to wevah29019 from comment #6)
> (In reply to Nate Graham from comment #5)
> > I'm wondering if there's an issue with memory leaking with an external
> > source (i.e. not KScreen) changed display settings. We have another report
> > of this when nvidia-settings changes it.
> > 
> > If you disable ARandR, does the issue stop happening?
> 
> You may misunderstand what ARandR does. It just generates scripts based on
> your current display config that can then be run to apply xrandr settings to
> apply those same settings again. It's not a service, there's nothing running
> and nothing to disable. I just occasionally need to run the scripts made
> with it to automate correcting the display configuration because it messes
> up every time a display device is added/removed.

In fact, I've noticed that when a device is turned on, and KDE messes up the desktop and I see the memory increasing nonstop that running the script to correct the display config can stop the memory from increasing. It never drops, but it can stop it from endlessly growing.

Interesting. Thanks for the clarification.

Could you submit another bug report detailing the issues you experience that cause you to need to use the manual workaround of running xrandr scripts? Ultimately our goal is for all of that to be unnecessary.

> Could you submit another bug report detailing the issues you experience that
> cause you to need to use the manual workaround of running xrandr scripts?

Yes. Though they seem very linked. Just to restate some more observations:

1) I start w/ 2 monitors (1440p) scale 150% at boot. All good.
2) After I turn on a 1080p receiver (which is configured to duplicate my left monitor) my right monitor goes out (is disabled) left monitor still works. Memory starts leaking. If I try to re-enable right monitor  in KDE's Display Config it does not turn on even thought the UI has been changed to enabled. 
3) If I run a script to apply the following (generated by ARandR:
xrandr --output HDMI-0 --mode 1920x1080 --pos 0x0 --rotate normal --output DP-0 --off --output DP-1 --off --output DP-2 --primary --mode 1920x1080 --pos 0x0 --rotate normal --output DP-3 --off --output DP-4 --mode 2560x1440 --pos 1920x0 --rotate normal --output DP-5 --off

This changes the resolution of the left monitor to 1080p (which it should), the right monitor starts working again at the original 1440p, and memory stop leaking.

Thanks. Can you submit a new bug report about the issue in step 2?

(In reply to Nate Graham from comment #10)
> Thanks. Can you submit a new bug report about the issue in step 2?

Done.

After updating to 5.27.2 I no longer get a memory leak when turning on the receiver. It turns on, both existing monitors stay working and things are OK.

Unfortunately I can still get the problem to occur if I then  turn on a projector that is attached to the receiver. It's odd. When the projector comes online my right monitor goes out (like what used to happen when the receiver was turned on) and no image is present on the projector. Whenever a screen goes out is when memory leaks seem to happen. But I can stop it, and make everything work, by using the projector's remote to switch its video source  from HDMI2 to HDM1 and then back to HDMI2. Something about making it go back and forth like that makes the image come thru. Then the image is shown on the projector and my other monitor starts working, and memory stops leaking.

This is such an odd edge case though. And since I understand how to  "correct" it, I am fine if you wish to close this.

There's still a bug *somewhere* that can get triggered when an external screen is connected. It's not just affecting you; various other people with multi-monitor setups--both weird and ordinary--are reporting it. So we'll need to investigate this and fix it. I'm happy to hear that it's no longer affecting your main use case though.

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

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

Check 466319. It could be related. Also causes plasmashell memory leak. Not multi-monitor.

Possibly related:
Bug 467284

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

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

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

Git commit 8309d691caa306e1c8035d725f523798b371e820 by Harald Sitter.
Committed on 12/04/2023 at 12:12.
Pushed by sitter into branch 'master'.

outputorderwatcher: don't leak replies

we are in charge of freeing xcb replies, so put them in a scopedpointer.
coupled with a refresh loop, caused by another defect, this lead to
excessive memory leakage.

M  +4    -3    shell/outputorderwatcher.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/8309d691caa306e1c8035d725f523798b371e820

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

Git commit 9385993e9dc8f1aae6aebd3c8c0dc86d71640325 by Harald Sitter.
Committed on 12/04/2023 at 12:13.
Pushed by sitter into branch 'master'.

outputorderwatcher: ignore outputs without crtc

when turning outputs **off** using `xrandr --off` that output is still
connected but won't have any crtc attached. this is distinctly different
from when kscreen disables an output, which indeed marks the output
disconnected but it still has a crtc

previously we would expect to find screens without crtc in the
list of `qApp->screens()` which would then trigger an infinite refresh
loop via the refresh timer because the screen would never be `present`
on account of being off.

M  +1    -1    shell/outputorderwatcher.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/9385993e9dc8f1aae6aebd3c8c0dc86d71640325

Git commit 364c617a1654b5bd0dc36379c9ab7056b21fe066 by Harald Sitter.
Committed on 12/04/2023 at 12:31.
Pushed by sitter into branch 'Plasma/5.27'.

outputorderwatcher: don't leak replies

we are in charge of freeing xcb replies, so put them in a scopedpointer.
coupled with a refresh loop, caused by another defect, this lead to
excessive memory leakage.


(cherry picked from commit 8309d691caa306e1c8035d725f523798b371e820)

M  +4    -3    shell/outputorderwatcher.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/364c617a1654b5bd0dc36379c9ab7056b21fe066

Git commit 951b72c1ed24c9c236883ca47bfe6a25883eca7f by Harald Sitter.
Committed on 12/04/2023 at 13:01.
Pushed by sitter into branch 'Plasma/5.27'.

outputorderwatcher: ignore outputs without crtc

when turning outputs **off** using `xrandr --off` that output is still
connected but won't have any crtc attached. this is distinctly different
from when kscreen disables an output, which indeed marks the output
disconnected but it still has a crtc

previously we would expect to find screens without crtc in the
list of `qApp->screens()` which would then trigger an infinite refresh
loop via the refresh timer because the screen would never be `present`
on account of being off.


(cherry picked from commit 9385993e9dc8f1aae6aebd3c8c0dc86d71640325)

M  +1    -1    shell/outputorderwatcher.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/951b72c1ed24c9c236883ca47bfe6a25883eca7f

Is there a workaround for this bug until 5.27.5 releases that doesn't involve rebooting?

(In reply to Alyx from comment #26)
> Is there a workaround for this bug until 5.27.5 releases that doesn't
> involve rebooting?

I'm regularly using `plasmashell --replace` to free the leaked memory

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

> I'm regularly using `plasmashell --replace` to free the leaked memory

When I do that I lose my task manager toolbar.

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