Skip to content

Wayland app quits with SIGTRAP when the compositor rejects a surface export #55141

Closed

Description

@shawnyeager

Preflight Checklist

Electron Version

44.9.1

What operating system(s) are you using?

Other Linux

Operating System Version

Arch Linux, kernel 7.2.8-9-omarchy (Wayland, Hyprland 0.56.2)

What arch are you using?

x64

Last Known Working Electron version

Unknown

Does the issue also appear in Chromium / Google Chrome?

I don't know how to test

Expected Behavior

The app stays open. One rejected Wayland surface export should not quit the process.

Actual Behavior

Granola, launched as /usr/lib/electron44/electron --ozone-platform-hint=auto /usr/lib/granola/app.asar, vanished after about 80 minutes. systemd-coredump recorded SIGTRAP for that process. The app started again on its own. No reliable steps to reproduce.

Testcase Gist URL

None. This was a one-off crash in a packaged app, not something I could reduce to an Electron Fiddle.

Additional Information

Wayland session under Hyprland 0.56.2. Chrome version string in the binary is 152.0.7977.167.

In-depth investigation

The faulting instruction is int3 followed by ud2. The main thread was in glib's main loop, in the Wayland event-source callback, in ui/events/platform/wayland/wayland_event_watcher.cc (WlDisplayDispatchPendingQueue). wl_display_dispatch_queue_pending had failed. rbx was 71 (EPROTO).

Crash-key memory held:

zxdg_exporter_v2#29: error 0: surface must be an xdg_toplevel

and compositor name Hyprland. Error 0 is invalid_surface on export_toplevel. The watcher then executes CHECK(err == EPIPE || err == ECONNRESET), so a protocol error traps instead of shutting down cleanly. Electron debug symbols were not available; those names come from strings in the function on the stack, the errno register, and the crash key.

Activity

  1. moved this to 👀 Unsorted Items in 44-x-yon Oct 20, 2026
  2. YUCLing commented on Oct 21, 2026

    @YUCLing
    Contributor

    Can you test if it also happens for Chromium? Chromium exports the surface when opening a file chooser too:

    [03:18:57.657629]  -> zxdg_exporter_v2#24.export_toplevel(new id zxdg_exported_v2#90, wl_surface#34)
    [03:18:57.657815] zxdg_exported_v2#90.handle("ed041120-4b75-4f57-8155-6a45362c4bf2")
    

    If it also crashes the Chromium, you will need to report this to Chromium team, as Electron reuses the Ozone from Chromium.

    If you don't know why/how to make your compositor reject a surface export, can you provide a stack trace? More information is needed to make the investigation easier.

  3. electron-issue-triage commented on Oct 21, 2026

    @electron-issue-triage

    Hello @shawnyeager. Thanks for reporting this and helping to make Electron better!

    Would it be possible for you to make a standalone testcase with only the code necessary to reproduce the issue? For example, Electron Fiddle is a great tool for making small test cases and makes it easy to publish your test case to a gist that Electron maintainers can use.

    Stand-alone test cases make fixing issues go more smoothly: it ensure everyone's looking at the same issue, it removes all unnecessary variables from the equation, and it can also provide the basis for automated regression tests.

    Now adding the blocked/need-repro Needs a test case to reproduce the bug label for this reason. After you make a test case, please link to it in a followup comment. This issue will be closed in 10 days if the above is not addressed.

  4. shawnyeager commented on Oct 22, 2026

    @shawnyeager
    Author

    Standalone case: https://gist.github.com/shawnyeager/075489575612c6d54abab381bca8e8ed

    dialog.showMessageBox with a BrowserWindow that has show: false quits the process on Wayland. The same call after the window has been shown does not.

    Reproduced twice on Electron 44.9.3, Arch Linux, Hyprland 0.56.2, --ozone-platform-hint=auto. stderr:

    libwayland: zxdg_exporter_v2#29: error 0: surface must be an xdg_toplevel

    The process then dies with SIGTRAP. Open the gist in Electron Fiddle, or run main.js with the system electron binary on Wayland.

  5. YUCLing commented on Oct 23, 2026

    @YUCLing
    Contributor

    @shawnyeager Thank you for your fiddle. I can produce this and I think this should be a Chromium side fix. Electron can only do the band-aid fix, so it cannot cover all cases, e.g.: https://gist.github.com/YUCLing/62834e17fb6a305dbd4d271ab811dc7e

    I'll see if I can make a repro with Chromium.

    Note: Some compositors will not check the export surface, e.g. KWin, so not all Wayland compositors can reproduce this.

  6. YUCLing commented on Oct 23, 2026

    @YUCLing
    Contributor

    Upstream CL: https://chromium-review.googlesource.com/c/chromium/src/+/8640149

    I've test the patch locally and it solves the crash, hope it can be upstreamed smoothly.

    Image
  7. basil commented on Nov 2, 2026

    @basil

    @YUCLing Any chance this could be backported to the Electron 45 line?

  8. YUCLing commented on Nov 2, 2026

    @YUCLing
    Contributor

    @basil Yes, as long as someone cherry-picks it. I might do it later.

  9. basil commented on Nov 3, 2026

    @basil

    @YUCLing Verified fixed as of 45.2.2. Thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions