Dear Maintainer,

kwin_wayland crashes with SIGSEGV when the set of outputs changes,
most often on resume from suspend while connected to an MST docking
station. On Wayland this takes down the whole session: plasmashell,
Firefox and Chromium all die alongside the compositor.

This is upstream KDE bug 504959, RESOLVED FIXED with 14 duplicates,
released in Plasma 6.4.5. Trixie ships 6.3.6 and is affected.

Frequency here: 7 kwin_wayland crashes in the last 14 days according
to coredumpctl. It is a race, so it does not reproduce on every
suspend cycle, but it recurs reliably in normal use.

Hardware: ThinkPad P14s (Ryzen AI 9 HX PRO 370, Radeon 890M, amdgpu),
ThinkPad Thunderbolt 4 dock with Synaptics MST hub driving external
displays. Kernel 7.1.8 and Mesa 26.1.2 from trixie-backports, both
far newer than the bug, which rules them out as the cause. A BIOS
update and a hardware dock replacement made no difference either.

Note: this system has trixie-backports pinned at high priority, hence
the newer kernel and Mesa. The kwin packages themselves are stock
trixie 4:6.3.6-1 (Plasma is not in backports).

Symbolised backtrace, with libkwin6-dbgsym installed:

  #4  KWin::ColorManagementOutputV1::ColorManagementOutputV1(
        wl_client*, unsigned int, unsigned int, KWin::Output*)
      src/wayland/colormanagement_v1.cpp:580
  #5-7  ffi_call (libffi)
  #8-10 wl_event_loop_dispatch (libwayland-server)
  #11 KWin::Display::dispatchEvents()
      src/wayland/display.cpp:121

A client binds wp_color_management_output_v1 via wl_registry.bind;
libwayland dispatches into KWin's handler, which dereferences a
KWin::Output* belonging to an output that has already been torn down.
Backtraces in the upstream duplicates show output=0x0 at exactly this
line.

Upstream fix:

  master:      e1fd647b979df7f0bd10065932a614a2aa806e87
  Plasma/6.4:  598438b9bcb9487c9dc85e4eb5f84e3b73a71051
https://bugs.kde.org/show_bug.cgi?id=504959

The change is small: +16/-6 in src/wayland/colormanagement_v1.cpp and
+3/-4 in the corresponding header. It prevents the object from
dereferencing the output handle after the underlying output has been
removed, since wl_output removal is inherently racy.

I verified that the upstream Plasma/6.4 commit 598438b9 applies
cleanly to the Debian 4:6.3.6-1 source, on top of the existing
debian/patches series, with no offsets and no fuzz. The package
already carries a number of upstream cherry-picks in debian/patches,
so this would follow the established pattern.

The 6.3 series is end-of-line upstream, so trixie will not receive this
fix through any 6.3.x release. Please consider cherry-picking it for a
trixie point release.

I have not yet run a patched build; the identification rests on the
matching backtrace and the upstream report. I am happy to build and
test a patched package and report back, given the crash rate here is
roughly one every two days.

Note this is a different bug from #1143050, which is upstream 495702 in
Workspace::activateNextWindow() (src/workspace.cpp) and fixed in 6.4.6.
Both are output-removal races in 6.3.6 affecting docked setups, but the
code paths and the fixes are separate.

I can provide full core dumps or journal excerpts on request.

Hey,

Thanks to your deep investigation into this topic and great analysis.

Th next step is to run a patch built to great such and test this.
I prepared a proposed update for trixie with the patch included (in the
debian/trixie branch on salsa).

https://salsa.debian.org/qt-kde-team/kde/kwin/-/tree/debian/trixie

Are you able to build that and test this on your laptop?
With the report from your side that it fixes you issue, we can than ask the
release managers to push this fix to stable.

Best regards,

hefee

Hey,
But we also need the data point that this patch fixes your issue on stable too.
When I request a poropsed update (pu) for stable via the release managers of
Debian, they want an answer how this patch was tested and a real world test
would be the best. Are you able to run Debian stable with only kwin patched to
check that this fixes your issue?
I can provide you the patched kwin packages, if you cannot create them
yourself.

Regards,

hefee

PS: please answer simple to 1147212@bugs.debian.org, as others from the Qt/KDE
packagers may want to follow the discussions and the release mangers will look
into the the bug report, when I request a pu.

I also repeatedly encountered this crash.  Using a Dell Precision laptop
with a Cable Matters dual DisplayPort USB-C connection with two
monitors.  I could reliably crash when disconnecting the hub.

With the patched kwin, I was unable to reproduce the crash over several
attempts.

Hey,

for Fabian the issues are fixed too. It seems like this bug is somehow
correlated with #1116619. But anyways together with the feedback from
Kushal im confident enough, that this patch fixes the issue.

Regards,

hefee

----------  Forwarded Message  ----------

Subject: Re: Bug#1147212: kwin-wayland: session crash in
ColorManagementOutputV1 on output change (fixed upstream in 6.4.5)
Date: Donnerstag, 1. Oktober 2026, 23:08
From: Fabian S.
To: Hefee

Hi,

good news. I think it fixed it reliably.

I recognized that with the packages from deltaone, only Firefox was
crashing. There is also someone talking about it in  message 57 from the
bugreport #1116619 I linked.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116619&pow_referer=#57

So I did go back to the standard debian packages. My test setup was
docked in, Firefox open, Thunderbird open, KeepassXC open. Then go to
standby, undock, wakeup, login.

With the standard packages. All three applications crash.

Deltaone only Firefox crashes.

With your packages I can not get it to crash. All three applications
stay open. Even with multiple tries.

I did reboots between those tests. Notebook is a Thinkpad L13 2in1 with
a Ultra 5 125U. Dockingstation is a Thunderbolt 3 Dock from Lenovo.

Do you need something else? We could also ask the people from the Debian
bugreport to test these packages.


Thank you

Hello,
I can confirm this crash on stock trixie with the same signature, and here it is
100% reproducible: kwin_wayland dies every single time I unplug the USB-C hub
that drives my displays. Adding the data point in case it helps the proposed
update.
Hardware / software
-------------------
  HP Elite x360 1040 14 inch G11 (Meteor Lake, Intel Arc iGPU on i915),
  BIOS W90 Ver. 01.08.01
  USB-C hub (VIA Labs based) driving two DisplayPort outputs over MST
  (card0-DP-5 / card0-DP-6) plus a Jabra Link 390 USB headset
  Debian 13 trixie, kernel 6.12.111+deb13-amd64, KDE Plasma 6.3.6 (Wayland)
  kwin-common/kwin-data/kwin-wayland/libkwin6 4:6.3.6-1
Signature (identical in both recorded incidents, 2026-10-06 23:27 and
2026-10-07 19:00 CST)
  19:00:58.055 pipewire: spa.alsa: front:1p: snd_pcm_start: Broken pipe
  19:00:58.282 kwin_wayland_wrapper: KCrash: Application
'kwin_wayland' crashing... crashRecursionCounter = 2
  19:00:59     systemd-coredump: Process 145998 (kwin_wayland) of user
1000 dumped core.
The compositor dies about 0.23 s after the dock's devices disappear: PipeWire
reports the ALSA devices going away and kded6 loses the
"alsa_input.usb-_Jabra_Link_390_..." objects, then every Wayland client dies
with it (Firefox, Zoom, PowerDevil, plasmashell). In the first incident the
same sequence is visible with "No such device" instead of "Broken pipe".
  $ coredumpctl list kwin_wayland
  Tue 2026-10-06 23:27:09 CST   1921 1000 1000 SIGSEGV /usr/bin/kwin_wayland
  Wed 2026-10-07 19:00:59 CST 145998 1000 1000 SIGSEGV /usr/bin/kwin_wayland
The backtrace in the journal matches the one in the original report. Symbolising
libkwin6 (6.3.6-1) through debuginfod gives exactly the same frame:
  #4  KWin::ColorManagementOutputV1::ColorManagementOutputV1(
        wl_client*, unsigned int, unsigned int, KWin::Output*)
      src/wayland/colormanagement_v1.cpp:580
  #5-7  ffi_call (libffi)
  #8-10 wl_event_loop_dispatch (libwayland-server)
  #11 KWin::Display::dispatchEvents()   src/wayland/display.cpp:121
The faulting instruction at that line is the member initialiser
`m_colorDescription(output->colorDescription())` with output == 0x0. Since
Output::colorDescription() is a trivial getter, the NULL `this` does not fault
inside the call: it returns a near-NULL source pointer and the subsequent
structure copy (rep movsq) is what raises SIGSEGV - which is precisely where
frame #4 points. So this is the same NULL `KWin::Output*` that the upstream
duplicates show.
The client triggering it on my system is Firefox: firefox-esr
153.4.0esr-1~deb13u1
is the only application in my session that speaks wp_color_manager_v1
(libxul.so references the interface; plasmashell, kded6, xdg-desktop-portal-kde
and OBS do not). In the second incident the last messages before the crash come
from firefox-esr, and in the first one Tor Browser's firefox.real (also
Gecko-based) coredumped immediately after kwin.
Testing the proposed update
---------------------------
I have built 4:6.3.6-1+deb13u1 from the debian/trixie branch in salsa: all 27
quilt patches, including upstream_e1fd647b and upstream_172f8f2e, applied
cleanly to the 6.3.6 source with no offsets and no fuzz. I am running the
patched libkwin6/kwin-wayland now and will follow up with the result of a
real-world test (several dock unplugs with Firefox open), as requested.
I can also provide the full core dumps or the relevant journal excerpts if that
is useful.
(For the record, I hit this in combination with the
Workspace::activateNextWindow() issue #1143050; as you noted, both are
output-removal races in 6.3.6 but they are clearly separate code paths.)
Thanks for preparing the update.