Repository navigation
cosmic-comp silently drops Chromium/Electron Wayland clients (ECONNRESET, no wl_display.error) #2894
Description
Edited Oct 3: this is not a regression. I've had it on three separate installs, long before these builds, including a fresh install after a few months on Windows. The first version blamed a commit range and named commits that aren't even in it. I've replaced that with what my logs actually show and what I've found in the code.
Chromium-family apps running native Wayland get their connection dropped by cosmic-comp several times a day on my machine. It isn't new: I've had it on three separate installs, going back well before these builds. On the current install it got much more frequent after the Sep 22 update (numbers below).
What happens
The app either dies at once with
ERROR:ui/events/platform/wayland/wayland_event_watcher.cc:78] Fatal Wayland communication error: Connection reset by peer.
or loses the socket, starts shutting down, and gets int3-trapped by Electron's 10 s session-loss shutdown watchdog when the shutdown doesn't finish in time:
kernel: traps: SessionLossShut[...] trap int3 ... in slack[...]
kernel: traps: OzoneShutdown W[...] trap int3 ... in paper-desktop[...]
Affected so far: Chrome 154, Brave, Slack 4.52, Paper (Electron 43/44), all native Wayland. cosmic-comp never crashes and logs nothing when it drops the client.
How often, on the current install
The kernel traps undercount badly, because they only fire when an Electron app takes longer than 10 s to shut down. A browser, or an Electron app that exits quickly, leaves no trace in the kernel log. The apps' own logs show the drops directly:
- Slack logs a bare
app.quitwith nobefore-quit/will-quitwhen it's dropped, and the full sequence when I quit it. Its logs (from Sep 22) show 18 drops from Sep 22 to Oct 3. Only 5 of those line up with a kernel trap. - Paper logs
Paper is quittingon a normal quit. Sessions that end without it, with no reboot or logout and not a second-instance handoff:- Sep 13 → Sep 22 12:46: 1 of 12 sessions (Sep 16 13:31)
- Sep 22 12:46 → Oct 3: 31 of 49 sessions
So the Sep 22 update (cosmic-comp a557859 → cd881a4, plus the rest of COSMIC moving to 1.9, Chrome 153 → 154 and a glib update) made it much more frequent here, but it was already happening before. a557859..cd881a4 is only four commits (f9e02f4, a7349b7, 651f701, cd881a4), and none of them obviously touches client connections. Over the same weeks my disk was getting worse (see below), so I can't separate the two.
WAYLAND_DEBUG capture of a drop
Full trace: https://gist.github.com/lkbddh/97defdc0eab8a4c9ff57e5122455712e
Brave's last requests, 2 ms before the socket died:
[23:38:38.322] -> wp_cursor_shape_device_v1#56.set_shape(20561463, 4)
[23:38:38.324] -> wl_surface#63.attach(nil, 0, 0)
[23:38:38.324] -> wl_surface#63.commit()
[23:38:38.324] -> wl_subsurface#67.destroy()
[23:38:38.326] Fatal Wayland communication error: Connection reset by peer.
What comes before that matters more. Comparing wl_pointer.motion event times with the client's own timestamps, Brave fell up to 1.6 s behind the compositor. In its last 20 ms it dispatched 288 queued motion events, covering about 1 s of compositor time. It was working through a backlog when the socket died, so the subsurface destroy is probably just the last thing it happened to send. The old title blamed subsurface teardown; I no longer think that's the trigger.
Likely mechanism (from reading the code, not confirmed)
No wl_display.error reaches the client. Chromium CHECK-fails on any connection error other than EPIPE/ECONNRESET (WlDisplayCheckForErrors in ui/events/platform/wayland/wayland_event_watcher.cc). So the client did not receive a protocol error. Two server-side paths end that way:
- Outgoing buffer overflow. cosmic-comp uses wayland-backend's Rust backend, where each client's buffer is 4096 bytes (
DEFAULT_MAX_BUFFER_SIZE, wayland-backend 0.3.15src/rs/mod.rs:11). When a write fails because the client isn't reading,send_eventcallsself.kill(DisconnectReason::ConnectionClosed)and sends no error (src/rs/server_impl/client.rs:210-211). Neither cosmic-comp nor smithay callsset_default_max_buffer_size. A client that stalls under a stream of pointer motion would hit this, and that fits the lag above. - A protocol error posted on an already-destroyed object, as in Ghostty quick terminal dies due broken pipe on hide #2159 / Commits to unmapped layer surfaces error after role object has been destroyed Smithay/smithay#1979. The client is killed, but the error never arrives.
State::disconnected (src/state.rs:178 at 0fbd457) gets the DisconnectReason but ignores it and logs nothing, so I can't tell these apart. Logging the reason and the client's pid there would settle it. If it's (1), raising the limit with set_default_max_buffer_size should help.
Other notes
surface missing from known popupsis probably unrelated: 399 times Sep 13 → 22, 791 since. In smithay it's the line logged in place of an error when a destroyed popup commits again.- My clients were also stalling on disk I/O. The SSD wasn't getting TRIM through LUKS, writes averaged about 250 ms, and IO pressure was 65–87% during the Oct 3 drops. I fixed that on Oct 3. If it's path (1), the drops should become rarer but not stop, since any long enough stall can still trigger one.
Environment
Pop!_OS 24.04 LTS, kernel 7.1.5-76070105-generic, cosmic-comp 0.1~1790118748~24.04~0fbd457, ASUS laptop, Ryzen AI 9 HX 370 + RTX 4070 (NVIDIA 595.84, hybrid, AMD iGPU drives the session).
Related: #2159, Smithay/smithay#1979, #2658 (silent exits; one comment reports native-Wayland Chrome dying with "Broken pipe" on 0fbd457, AMD+NVIDIA), pop-os/cosmic-epoch#3630 (Chromium freeze/hang on COSMIC + NVIDIA hybrid), pop-os/cosmic-epoch#3417 + #2349 (popup tracking).
I have an apport SIGTRAP report with a core dump for paper-desktop, the full journals, and the WAYLAND_DEBUG trace. This happens several times a day here, so I'm happy to test patches or a debug build that logs the disconnect reason.
Activity
[-]cosmic-comp silently severs Wayland connection of Chromium clients on subsurface teardown (regression in a557859..cd881a4)[/-][+]cosmic-comp silently drops Chromium/Electron Wayland clients (ECONNRESET, no wl_display.error) since the Sep 22 COSMIC 1.9 update[/+][-]cosmic-comp silently drops Chromium/Electron Wayland clients (ECONNRESET, no wl_display.error) since the Sep 22 COSMIC 1.9 update[/-][+]cosmic-comp silently drops Chromium/Electron Wayland clients (ECONNRESET, no wl_display.error)[/+]A9G-Data-Droid commentedon Oct 10, 2026
I have been struggling with this for a weeks and I couldn't live with it, so I undertook making a fix.
I can regularly reproduce the silent ECONNRESET drops on Brave/Chromium with my monitor running at 144Hz and confirmed the root cause:
wayland-backenddefaults to a fixed 4 KiB limit (DEFAULT_MAX_BUFFER_SIZE). When high event rates (144Hz vblank / mouse pointer with a high report rate) coincide with brief client stalls,flush()returnsWouldBlock, the buffer cannot expand, andwayland-backendterminates the client withself.kill(DisconnectReason::ConnectionClosed)without sending a protocol error.Enabling the
libwayland_1_23feature onwayland-serverandwayland-backendexposesset_default_max_buffer_size. Increasing the default client max buffer size to 2 MiB ininit_wayland_displayresolved the drops completely.I am running my fixed binary on my Desktop and my computer is usable again. I have an example on this branch: https://github.com/A9G-Data-Droid/cosmic-comp/tree/fix-2894-vrr-texture-import
I went to open a PR but I noticed that you don't accept PRs with LLM generated content. I am an AI engineer at my day job. I can open a PR if what I have here is acceptable. Or someone could look at my solution and rewrite it by hand if that is what you need to do. I'll be running my version until it gets fixed upstream.
81reap commentedon Oct 24, 2026
I've run into this issue a few times on my NixOS machine. I thought it was just a transient thing since logs don't show any obvios signs of crashing but after the Nth time of it happening I put claude-code on the case.
my machine and env
e7439b6), kernel 6.18.55epoch-1.9.0--ozone-platform-hint=auto(NIXOS_OZONE_WL=1)what happened?
VS Code (Electron 43.7.3) and ungoogled-chromium 154, both native Wayland, exited 133 ms apart. Both had been running for 8 days:
coredumpctl, no new Crashpad report from either app, and no OOM kill./dev/null.suspected root cause
At the time of the crash, Steam was trying to update Fallout 76 but my drive had one bad sector that the game was installed on. Steam read about 500 MiB/s from the disk without stopping and set off ATA error recovery over and over (
Unrecovered read error - auto reallocate failed, 1,131 times since 03:06). The same disk holds/nix/store,/homeand swap, so any page fault in either app had to wait behind that. About 10 minutes after the drop,/proc/pressure/ioreadsome avg300=19.52andfull avg300=15.45. I didn't record pressure at the moment of the drop itselfThis matches what the outgoing buffer issue called out in the orignal report :: clients stalled on disk I/O, and the drops got rarer once the disk was fixed (uninstalling Fallout 76 and reinstalling it in my case). A client that stops reading for a moment while the compositor keeps sending events would fill the 4 KiB per-client buffer. The compositor then calls
kill(DisconnectReason::ConnectionClosed)without sending a protocol error.surface missing from known popupsappears 344 times in my boot's cosmic-comp log (8 days), but I suspect it's probably unrelated.workaround
I'm currently running
badblocksand S.M.A.R.T. scans to find any other bad blocks/sectors on my drive to fix those by moving files and folders off of those blocks/sectors. I wrote about these tools on my blog if others want to try scanning their own drives https://prayag.bhakar.org/blog/post/being-smart-about-used-storagetobico commentedon Oct 28, 2026
I've been running into this issue with Brave. I have a 144hz monitor and high refresh rate gaming mouse, and frequently run multiple rust compilations in the background. A lag spike of around 5 seconds from Brave, often associated with loading a YouTube video, causes it to get terminated.
Here's a log I was able to capture of the issue in action: