Bug 425271

Created attachment 131114 [details]
upgraded packages resolved the issue

After the latest system upgrade, the problem vanished, so one of the upgraded packages resolved the issue. Fur further investigation please see the attaced list.

Sorry, my first impression was wrong, there is still a high cpu usage in certain circumstances, e.g. directly after reboot and a start of program with tray icon.

I can confirm this issue on KDE Neon User Edition (Ubuntu 20.04)

@kde Do you have a NVIDIA GPU too?

@Stefan: Actually yes

See details:
product: GM107M [GeForce GTX 850M]
vendor: NVIDIA Corporation

Then I assume that's an issue with the nvidia driver. I can't reproduce this issue on my notebook (Intel GPU).

On my desktop computer the issue occurs at least with nvidia driver 450.x and 455.y.

>If I start XembedSNIProxy in shell, I got following messages:

Nothing has changed in xembedsniproxy in years. Could you get a snapshot with:
perf record --call-graph dwarf xembedsniproxy

Ideally with debug symbols. 

I don't see how it could be nvidia, there's no GL involved in any of this.

I've installed the package plasma-workspace-dbg before running perf:
https://nextcloud.draakgard.de/nextcloud/index.php/s/nCiFPiRcozFaBfx

thanks

Created attachment 132118 [details]
perf data (without debug info)

my perf data is smaller, but unfortunately without debug infos.

At the moment I don't observe this issue. I've upgraded to Plasma 5.20.0. And I've enabled the auto-start of the compositor again (there was a message box in the compositor settings).

Ok I've observed this issue again: The OpenGL detection of the compositor was disabled. After re-enabling the issue vanished.

I have this problem too on KDE Plasma 5.21.1, framework version 5.79.0, running on X11 and proprietary nvidia drivers on a GTX 1070.

It spam the message "Container window visible, stack below" so bad that it filled my drive fairly quickly, I had to disable the session log file from sddm. It also make everything unresponsive as the X server is also running at 100%.

More info: I'm using 3 monitors, 2 bars have a system tray and both of them are vertical on the left side of their screen.

@northon_patrick3 - do you have anything unusual installed or run? Can you check on new, fresh user? It this issue specific to one application? Any non-default setting for Kwin?

(In reply to Konrad Materka from comment #15)
> @northon_patrick3 - do you have anything unusual installed or run? Can you
> check on new, fresh user? It this issue specific to one application? Any
> non-default setting for Kwin?

It's no longer doing it and I haven't changed anything, only installed updates. I'm on Arch (btw) which get frequent updates. I can however provide a few more clues: I noticed that it would always happen when I started Firefox. I have the plasma integration add-on in Firefox. I'm not sure if it's the only way but I could reproduce it consistently.

I have the same issue, it has plagued me for a long time now across two different installs of Manjaro. My issue too seems to be caused by Firefox running. In my case, if I try to open keepass, discord or element while Firefox is running (especially keepass), xsembedsniproxy goes crazy spamming my logs with "Container window visible, stack below" which brings xorg to its knees until i close the offending application.

I have noticed that with compositing turned on, the issue seems to go away, but I prefer it off because it is jittery and robs GPU resources. GTX1080 (nvidia drivers) and triple monitor here as well.

intlhouseofdan, can you be more specific? Which version of Keepass are you using? On my distro (Neon) I have 3:
* keepassx (uses SNI)
* keepassxc (uses SNI)
* keepass2 (implemented in Mono, uses XEmbed) - only this one can cause troubles

Do you have any addons installed in Firefox that comunicates with Keepass?

I'm trying to reproduce this issue but I can't without more precise description.

I'm using firefox too but not keepass

I'm observing the same behaviour with high cpu usage from xembedsniproxy. In my case I'm pretty sure it comes in combination with evolution-alarm-notify.

I first observed the high cpu after switching from Thunderbird to Evolution.
After some try and error with starting and stopping of evolution at all i found out that killing xembedsniproxy OR evolution-alarm-notify instantly stops the high cpu usage.

I'm also using firefox and keepassxc, but that combination never made problems until using evolution-mail.

Also running with nvidia (RTX 2060) and two monitors (Notebook build-in HD and external WQHD).

Compositing was turned off so far.

SOFTWARE/OS VERSIONS
Operating System: openSUSE Leap 15.2
KDE Plasma Version: 5.18.6
KDE Frameworks Version: 5.71.0
Qt Version: 5.12.7
Kernel Version: 5.3.18-lp152.84-preempt
OS Type: 64-bit
NVIDIA driver: 470.57.02-lp152.43.1

I can reliable reproduce the issue when starting VeraCrypt.

SOFTWARE/OS VERSIONS
Operating System: Manjaro Linux
KDE Plasma Version: 5.22.4
KDE Frameworks Version: 5.84.0
Qt Version: 5.15.2
Kernel Version: 5.10.56-1-MANJARO (64-bit)
Graphics Platform: X11
Graphics Processor: NVIDIA GeForce GTX 1050 Ti/PCIe/SSE2
NVIDIA driver: 470.57.02

I can confirm too.

Operating System: Debian GNU/Linux 11
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Kernel Version: 5.10.0-8-amd64 (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 630

It's happening for me on openSUSE Tumbleweed as well, only when the Software Reneder is enabled. I can generate a perf on-cpu trace, but it's too big to be uploaded here and generating a report with perf script consumes all my memory before it's done.

Instead, I'll upload screenshots of overviews from hotspot with the perf trace loaded..

Created attachment 142396 [details]
picture of flame graph with SW renderer enabled

Created attachment 142397 [details]
picture of flame graph with SW renderer disabled (OpenGL used)

(In reply to Konrad Materka from comment #18)
> intlhouseofdan, can you be more specific? Which version of Keepass are you
> using? On my distro (Neon) I have 3:
> * keepassx (uses SNI)
> * keepassxc (uses SNI)
> * keepass2 (implemented in Mono, uses XEmbed) - only this one can cause
> troubles
> 
> Do you have any addons installed in Firefox that comunicates with Keepass?
> 
> I'm trying to reproduce this issue but I can't without more precise
> description.

Sorry for the late reply. I am using what I believe is keypass2 v2.49 which is in the official repos for Manjaro.

Actually, it's happening with software rendering disabled too, now. I'll see if I can find the common cause in another perf trace.

FWIW, my xembedsniproxy version is 5.22.5-3.1.

> I'm trying to reproduce this issue but I can't without more precise
> description.

I'll add which programs I'm using which seem to reproduce this.

- the element matrix client, element-1.9.2-1.suse.tw.taw, from the repo https://github.com/taw00/element-rpm/
- gajim, gajim-1.3.2-1, from the official oss opensuse tumbleweed repos

KDE and system versions:

Operating System: openSUSE Tumbleweed 20211016
KDE Plasma Version: 5.23.0
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Kernel Version: 5.14.11-1-default (64-bit)
Graphics Platform: X11
amdgpu driver

For me this happens consistently with BackInTime, usually when it runs after resuming from suspend. When it is doing a backup and the notification area icon is shown, xembedsniproxy uses ~65% CPU (and xorg 100%).

I am experiencing the same issue with Nextcloud and Firefox when I stop the compositor. The moment the compositor is stopped, Xorg process pins CPU at 100% and xembedsniproxy goes to approximately 65%, with the logs spamming the same message, xembedsniproxy: Container window visible, stack below. This locks up the system - htop updates once every 30 seconds at best, Firefox and Discord freeze completely, and any game running freezes as well. If a terminal is not already open and selected for me to rectify (by restarting the compositor), the system must be forcibly rebooted.

I discovered this issue with Lutris - its disable compositor option froze my system. This isn't 100% reproducible for me, for example I just closed Nextcloud and Firefox and reopened them, and no error occurred. But it can start randomly - I have also experienced opening a link from Discord while in a game, and it opened Firefox - completely freezing the system.

Manjaro, KDE Plasma 5.23.3, Frameworks 5.88.0, Qt Version 5.15.2, Kernel 5.13.19-2-MANJARO, NVIDIA 3080 GPU.

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

>only when the Software Reneder is enable

Which software rendererer are you referring to?

We have some logic in xembedsniproxy that says "if our hidden window is shown, send it to the back again".  Clearly someone else is putting our window back again. Possibly a new kwin change.

Can you confirm that openbox --replace silences the issue?
Can you also enable any debug in kwin and see if that shows anything?

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

(In reply to David Edmundson from comment #32)
> We have some logic in xembedsniproxy that says "if our hidden window is
> shown, send it to the back again".  Clearly someone else is putting our
> window back again. Possibly a new kwin change.
> 
> Can you confirm that openbox --replace silences the issue?
> Can you also enable any debug in kwin and see if that shows anything?

Ah, interesting. I'm using i3, so no kwin for me. I'll try i3 --replace when this happens to see if it changes anything.

I gave up on this getting fixed and just close it as soon as the system boots. I can live without the icons in the tray.

I have this problem too. And I must kill xembedsniproxy. After xembedsniproxy is killed, nothing happens but some windows start to have a white thin border.

intlhouseofdan - some versions of keepass still use old XEmbed protocol to display tray icon. Your issue is unrelated to Firefox. 

zyf0330 and intlhouseofdan: Can you give more details about your setup? Are you using different compositor or desktop manager? Did you change any setting (for example, software rendering)?

As a workaround, you can use:

killall xembedsniproxy; wmsystemtray --non-wmaker --bgcolor white

This will show XEmbed tray icons in a separate window. All modern tray items (SNI) will work as currently, unimpacted.

Created attachment 145829 [details]
Compositor settings

I use Ubuntu 21.10 with KDE Plasma, and SDDM compositor whose settings is in attachment.

After do that workground, there are three tray icons appearing in separate window. They are emojione-picker, xpad, wine.

Another related thing is, after change compositor settings (when use OpenGL 3.1 or OpenGL 2.0) and apply, the whole screen is lag, except I use Xrender. My previous computer has no this problem, current computer is too old which is MSI GE60 2PG. So Maybe it is a hardware compatibility problem.

(In reply to zyf0330 from comment #38)
> Created attachment 145829 [details]
> Compositor settings
> 
> I use Ubuntu 21.10 with KDE Plasma, and SDDM compositor whose settings is in
> attachment.
> 
> After do that workground, there are three tray icons appearing in separate
> window. They are emojione-picker, xpad, wine.

It is weired, I try to retry but this problem disappears.
I try to disable all these three applications autostart, and enable one by one, at the same time I switch Render Backend between OpenGL 3.1 and Xrender, but XembedSNIProxy doesn't use high cpu every reboot. AND, I resume all these settings, this problem doesn't appear too!

The only variable is, I changed kernel version from 5.13.0-22-generic to 5.13.0-27-generic before do this. But switch Render Backend to OpenGL is still lag, unless I set OpenGL and reboot and doesn't touch Compositor settings.

Screen recording: <https://photos.app.goo.gl/2vxdDmsFdpNhsb596> (50 seconds) – starting Remmina.

Observe the clock (bottom left) pause at 09:33:16 (around 00:28 on the timeline), again at 09:33:24, again at 09:33:27, again at 09:33:36. 

Hogging of the CPU is visible more in GKrellM (to the right) than in htop (background). 

Generally, the desktop environment becomes almost completely unresponsive until I kill: 

/usr/local/bin/xembedsniproxy

For me, the problem: 

* began a few weeks ago – almost certainly before Friday 4th March
* is reproducible on campus, with a wired network connection
* is _not_ reproducible at home, with a wired network connection. 

### Environment

Operating System: FreeBSD 14.0
KDE Plasma Version: 5.24.3
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.2
Kernel Version: 14.0-CURRENT (64-bit)
Graphics Platform: X11
Memory: 15.9 GiB of RAM
Graphics Processor: AMD TURKS

% pkg provides /usr/local/bin/xembedsniproxy
Name    : plasma5-plasma-workspace-5.24.3_2
Desc    : Plasma5 Plasma workspace
Repo    : FreeBSD
Filename: usr/local/bin/xembedsniproxy
% pkg info -x net/remmina x11/plasma5-plasma-workspace
remmina-1.4.17
plasma5-plasma-workspace-5.24.3_2
% pkg -vv | grep -e url -e enabled
    url             : "pkg+http://pkg0.pkt.freebsd.org/FreeBSD:14:amd64/latest",
    enabled         : yes,
    url             : "https://alpha.pkgbase.live/current/FreeBSD:14:amd64/latest",
    enabled         : no,
    url             : "file:///usr/local/poudriere/data/packages/main-default",
    enabled         : yes,
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #7 main-n253861-92e6b4712b5-dirty: Sat Mar 19 02:40:21 GMT 2022     root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400053 1400053
%

I might have some insight to provide, or mine is just a weird extra edge case triggering a similar problem. Basically the problem of high cpu only occurs depending on how I have my screens setup relative to each other.

If I have my upper screen moved to the right, right aligned with the screen below it so there is a gap on the left, the issue occurs after hitting apply. See pic: https://i.imgur.com/JW1jWEk.png

If I have my upper screen moved to the left, left aligned with the screen below it so there is a gap on the left, the issue is gone after hitting apply. See pic: https://i.imgur.com/f24r5M4.png

If I have my screens all along a horizontal line, no issue.

When the issue is occuring, Xorg is doing 96% cpu usage, xembedsniproxy is doing 78% cpu usage, and kwin_x11 is doing 63% cpu usage, cpu is i7 4790K.

Compositor is off.

Operating System: KDE neon 5.19
KDE Plasma Version: 5.19.4
KDE Frameworks Version: 5.72.0
Qt Version: 5.14.2
Kernel Version: 4.15.0-corobuild-acso
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz
Memory: 31.4 GiB of RAM
Graphics Processor: GeForce GTX 1070 Ti/PCIe/SSE2

Created attachment 148178 [details]
Screen recording

(In reply to Graham Perrin from comment #41)

> … For me, the problem: 
> 
> * began a few weeks ago – almost certainly before Friday 4th March
> * is reproducible on campus, with a wired network connection
> * is _not_ reproducible at home, with a wired network connection. 
> 
> ### Environment
> 
> … 

I'm not yet certain, but from a few test results I suspect that I can avoid the issue (on campus) by using the JavaEmbeddedFrame in my system tray to quit LanguageTool before starting Remmina. 

This screen recording (at home, without attempting to start Remmina) shows use of the context menu for the JavaEmbeddedFrame icon for LanguageTool. 

<https://dev.languagetool.org/http-server>

I have the same behavior as Kevin Gagnon ( comment #42) in a "more traditional" setup: I've two monitors, one external (21:9 curved, but maybe it's not relevant), and the laptop built-in.
My laptop is physically on my right so my conf is:
LAPTOP Screen | EXTERNAL
In this scenario, when I use the openlens application, I suffer the high CPU usage of XembedSNIProxy.
Keeping the application opened and flipping the display configurations as follows:
EXTERNAL | LAPTOP Screen
make the issue disappears.
Additionally, making one display primary or vertical align the laptop screen on the top line doesn't change anything.


SOFTWARE/OS VERSIONS
Archlinux
KDE-Plasma-Version: 5.24.5-2
Qt-Version: 5.15.4
Kernel-Version: 5.15.41-1-lts
64-bit

Oh wow, yeah, I just tried reproducing Kevin Gagnon's  "workaround" and placing the laptop screen to the left of the external screen in system settings does stop xembedsniproxy from spamming to the journal. That's pretty mindblowing.

To specify, my settings change changed the following two lines of `xrandr` output:

eDP-1 connected primary 1920x1080+0+420 (normal left inverted right x axis y axis) 344mm x 194mm
HDMI-1-0 connected 1080x1920+1920+0 left (normal left inverted right x axis y axis) 531mm x 299mm

to:

eDP-1 connected primary 1920x1080+1080+520 (normal left inverted right x axis y axis) 344mm x 194mm
HDMI-1-0 connected 1080x1920+0+0 left (normal left inverted right x axis y axis) 531mm x 299mm

SOFTWARE/OS VERSIONS
Archlinux
KDE-Plasma-Version: 5.25.3
Qt-Version: Qt 5.15.5
Kernel-Version: 5.18.14
64-bit

I've done a little more digging with the geometry. There are "bad" layouts, where XembedSNIProxy is noisy, and "good layout", where it doesn't complain.  If the config is wrong, xembedsniproxy dumps hundreds of thousands of logs. I initially thought they were being printed periodically, roughly every 30s, for about 2s, but they were instead simply getting suppressed by systemd, given `systemd-journald[218]: [🡕] Suppressed 195123 messages from user@1000.service)` reocurring.

I'm going to attach a few screenshots of the "map" of layouts, but the gist is: in a dual monitor setting, IF the external monitor is to the right of the main monitor AND has its top border anywhere above the extent of the main monitor, xembedsniproxy starts spamming. This is true whether the external monitor is in horizontal or vertical mode. 

Does anyone have ideas on why that might be?

Created attachment 150937 [details]
.tar.gz archive of 8 screenshots forming a map of "good" and "bad" screen layouts

The screen layout discovery is great, I have extra portrait monitor that has top edge higher. I usually do a quick "killall xembedsniproxy" right after logging in, but forgot today, so it was running for about 8 hours. Session log has over 10 **million** lines of "Container window visible, stack below"

So basically it's "bad" if there's no screen at 0,0 in global space. 

Thanks. That should be enough to help trigger this locally.

It is amazing. With this setup (smaller monitor on the left, vertically centered) my ~/.xsession-errors is spammed with huge volume of „Container window visible, stack below”:

https://pasteboard.co/FoXmuIxWfCuD.png

Moving left screen  slightly up (so tops are aligned), puff, problem gone:

https://pasteboard.co/SNQYJxFRSZMd.png

It happens immediately, Apply in Display settings window and it stops/starts.

(In reply to Marcin Kasperski from comment #50)
> It is amazing. With this setup (smaller monitor on the left, vertically
> centered) my ~/.xsession-errors is spammed with huge volume of „Container
> window visible, stack below”:
> 
> https://pasteboard.co/FoXmuIxWfCuD.png
> 
> Moving left screen  slightly up (so tops are aligned), puff, problem gone:
> 
> https://pasteboard.co/SNQYJxFRSZMd.png
> 
> It happens immediately, Apply in Display settings window and it stops/starts.

same here with vertical monitor setup (up / down).
When aligning both to the left edge, the error is instantly gone.

With center alignment applied, the ~/.xsession-errors is flooded with "Container window visible, stack below".
in the 15 seconds until automatic config rollback after reply i got 118966 error lines. 

> $ tail -fn0 .xsession-errors  | ts > /tmp/.xsession-errors.ts    # while the 15 seconds of center aligned setup
> $ grep -c "Container window visible, stack below" /tmp/.xsession-errors.ts
> 118966

Packages (@Linux Mint 21):
> plasma-workspace 4:5.24.7-0ubuntu0.1 from ubuntu/jammy-updates (contains xembedsniproxy)
> plasma-desktop 4:5.24.7-0ubuntu0.1 from ubuntu/jammy-updates

So glad I stumbled upon this. I was seeing log spam and plasmashell freeze up when I went full screen in mpv. aligning the borders of the monitors makes things go away, as suggested. Very frustrating these needs to be done for my workspace, though

This is probably caused by the fix to https://bugs.kde.org/show_bug.cgi?id=357443.

There's this bit in fdoselectionmanager.cpp

> else if (responseType == XCB_VISIBILITY_NOTIFY) {
>       const auto event = reinterpret_cast<xcb_visibility_notify_event_t *>(ev);
>        // it's possible that something showed our container window, we have to hide it
>        // workaround for BUG 357443: when KWin is restarted, container window is shown on top
>        if (event->state == XCB_VISIBILITY_UNOBSCURED) {
>            for (auto sniProxy : m_proxies.values()) {
>                sniProxy->hideContainerWindow(event->window);
>            }
>        }
>    }

Where does the XCB_VISIBILITY_UNOBSCURED event originate? Is it a bug that a window is reported as unobscured if it's located on an offscreen position? Or is it the responsibility of the client to check if the window is unobscured and on-screen?

Hi, any chance this bug gets fixed? Still happens with Plasma 6.0.4

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

Git commit efecf88d2d77d8f4cd94edb3a83d10deb16a1e92 by Konrad Materka.
Committed on 23/05/2024 at 12:34.
Pushed by kmaterka into branch 'master'.

xembedsniproxy: Fix high CPU usage when 0,0 is off-screen

Reverts 69786a1ff94718daf4de2d814037e70df079ec97, which is no longer needed after 50bbe56bb08f9b265ad56510e2adc37db66f4d2d

Initial workaround for Bug 357443 tries to detect and fix window stacking issues (for example after compositor restart). Unfortunately, it causes infinite loop when (0,0) position (were windows are originally positioned) is off-screen (this can happen in some less commonmulti-screen setups).
Proper fix was added in !4324, so that faulty workaround is no longer needed.

M  +0    -9    xembed-sni-proxy/fdoselectionmanager.cpp
M  +1    -14   xembed-sni-proxy/sniproxy.cpp
M  +0    -2    xembed-sni-proxy/sniproxy.h

https://invent.kde.org/plasma/plasma-workspace/-/commit/efecf88d2d77d8f4cd94edb3a83d10deb16a1e92