Repository navigation
fix(linux): report a failed display open as Unavailable in raw display handles - #1351
Merged
Legend-Master merged 2 commits intoOct 5, 2026
Merged
Conversation
…y handles Both Linux `raw_display_handle_rwh_06` implementations passed a failed (null) `XOpenDisplay` result into `XDefaultScreen` and `NonNull::new_unchecked`, which is undefined behavior in Xlib and in Rust respectively, in a safe `pub fn` returning `Result`. The Wayland branch did the same with `gdk_wayland_display_get_wl_display` without a null check. Both now return `Err(HandleError::Unavailable)` on a null display. The `rwh_05` variants also skip calling `XDefaultScreen` on a null display (no error path is available there). Fixes tauri-apps#1347
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The reviewed changes safely address the reported Linux display-handle failures.
Review effort: Lite
Findings: None
What changed in this PR
Fixes Linux raw display handle undefined behavior by safely handling unavailable X11 and Wayland displays.
Changes:
- Checks null X11 and Wayland display pointers.
- Returns
HandleError::Unavailableforrwh_06failures. - Avoids
XDefaultScreen(NULL)forrwh_05. - Adds a changelog entry.
| File | Description |
|---|---|
src/platform_impl/linux/window.rs |
Adds X11 and Wayland null checks. |
src/platform_impl/linux/event_loop.rs |
Adds X11 and Wayland null checks. |
.changes/fix-display-handle-null-checks.md |
Documents the fix. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Legend-Master
requested changes
Sep 30, 2026
Contributor
|
The idea looks good to me by the way, thanks. |
marrionesa
commented
Oct 2, 2026
Legend-Master
approved these changes
Oct 5, 2026
Contributor
Package Changes Through 9f977ddThere are 1 changes which include tao with patch Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Fixes #1347.
Both Linux
raw_display_handle_rwh_06implementations (event_loop.rsandwindow.rs) passed a failedXOpenDisplayresult (null) intoXDefaultScreenand then intoNonNull::new_unchecked. The first is undefined behavior in Xlib, the second is undefined behavior in Rust (unwrapof a null pointer) — and both happen inside a safepub fnthat already returnsResult. The Wayland branch had the same shape:gdk_wayland_display_get_wl_displaywas unwrapped withNonNull::new_uncheckedwithout a null check.With this change:
rwh_06, both files): a null return fromXOpenDisplaynow yieldsErr(HandleError::Unavailable);XDefaultScreenis only called with a valid display, and the handle is only built from a checkedNonNull.rwh_06, both files): a nullwl_displaynow yieldsErr(HandleError::Unavailable)instead ofNonNull::new_uncheckedUB.rwh_05, both files): there is no error path in the 0.5 API, so the handle keeps the pre-existing "null display" shape on failure, butXDefaultScreen(NULL)(also UB) is no longer called — the fields are simply left empty.rwh_06::HandleError::Unavailableis the same error the functions already return when thex11feature is disabled orXlib::open()fails, so consumers already have to handle this variant; this change only makes the code stop UB-ing on the way to it.Testing
cargo check -p taoandcargo check -p tao --features rwh_05: clean (therwh_05code is not compiled by default features, the fixed X11/XWayland paths are).cargo clippy -p tao --features rwh_05: no warnings on the touched files.cargo test -p tao: all pass.examples/display_handle_check.rs, kept out of this PR, in #16089-style standalone fashion) on Linux:display_handle()returnsOkwith bothGDK_BACKEND=x11(Xlibhandle with valid display + screen) and Wayland (default backend on the test machine), so the success path of the reworked branches is exercised end to end.new_unchecked'd, so it only converts a UB path into the already-existingErrvariant.