SIGSEGV with clean dioxus project on desktop linux

[maya-ashley0]

Problem

dx serve on desktop linux result in Application [linux] exited with error: signal: 11 (SIGSEGV) (core dumped)

Steps To Reproduce

Steps to reproduce the behavior:

1. Create a new dioxus app targeting Desktop Linux
2. Run dx serve
3. It core dumps (and the status doesn't indicate failure)

Expected behavior

I'd expect the app to be served as expected.

Screenshots

> dx new dioxus-example
✔ 🤷   Which sub-template should be expanded? · Bare-Bones
✔ 🤷   Do you want to use Dioxus Fullstack? · false
✔ 🤷   Do you want to use Dioxus Router? · false
✔ 🤷   Do you want to use Tailwind CSS? · false
✔ 🤷   Which platform do you want DX to serve by default? · Desktop
   5.129s  INFO Generated project at /home/user/git/dioxus-example

`cd` to your project and run `dx serve` to start developing.
If using Tailwind, make sure to run the Tailwind CLI.
More information is available in the generated `README.md`.

Build cool things! ✌️
> cd dioxus-example/
> dx serve
21:56:28 [dev] -----------------------------------------------------------------
                Serving your Dioxus app: dioxus-example
                • Press `ctrl+c` to exit the server
                • Press `r` to rebuild the app
                • Press `p` to toggle automatic rebuilds
                • Press `v` to toggle verbose logging
                • Press `/` for more commands and shortcuts
                Learn more at https://dioxuslabs.com/learn/0.6/getting_started
               ----------------------------------------------------------------
21:58:27 [dev] Build completed successfully in 118523ms, launching app! 💫
21:58:28 [dev] Application [linux] exited with error: signal: 11 (SIGSEGV) (core dumped)
╭────────────────────────────────────────────────────────────────────────────────────────── /:more ╮
│  App:     ━━━━━━━━━━━━━━━━━━━━━━━━━━  🎉 118.7s    Platform: Desktop Linux                       │
│  Bundle:  ━━━━━━━━━━━━━━━━━━━━━━━━━━  🎉 0.2s      App features: ["desktop"]                     │
│  Status:  Serving dioxus-example 🚀 118.9s         ServerFns at: no server address               │
╰──────────────────────────────────────────────────────────────────────────────────────────────────╯

Environment:

• Dioxus version: dioxus 0.6.3 (was built without git repository)
• Rust version: rustc 1.87.0 (17067e9ac 2025-05-09)
• OS info: Arch Linux running Linux 6.12.29-1-lts #1 SMP PREEMPT_DYNAMIC x86_64 GNU/Linux (I installed the dependencies for Arch Linux as documented here, and I only have wayland installed -- I do not have Xwayland)
• App platform: Desktop Linux

Questionnaire

I'm interested in fixing this myself but don't know where to start.

[maya-ashley0]

> DEBUGINFOD_URLS=https://debuginfod.archlinux.org valgrind target/debug/dioxus-example
==3871== Memcheck, a memory error detector
==3871== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==3871== Using Valgrind-3.25.1 and LibVEX; rerun with -h for copyright info
==3871== Command: target/debug/dioxus-example
==3871==
==3871== Thread 15:
==3871== Invalid read of size 4
==3871==    at 0xDFE9464: XDefaultRootWindow (Macros.c:52)
==3871==    by 0x463C2B2: global_hotkey::platform_impl::platform::events_processor (mod.rs:192)
==3871==    by 0x463B7F2: global_hotkey::platform_impl::platform::GlobalHotKeyManager::new::{{closure}} (mod.rs:31)
==3871==    by 0x4630062: std::sys::backtrace::__rust_begin_short_backtrace (backtrace.rs:152)
==3871==    by 0x464E1A2: std::thread::Builder::spawn_unchecked_::{{closure}}::{{closure}} (mod.rs:559)
==3871==    by 0x4630F20: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once (unwind_safe.rs:272)
==3871==    by 0x46302FF: std::panicking::try::do_call (panicking.rs:589)
==3871==    by 0x465064A: __rust_try (in /home/user/git/dioxus-example/target/debug/dioxus-example)
==3871==    by 0x464DF7B: try<(), core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<global_hotkey::platform_impl::platform::{impl#0}::new::{closure_env#0}, ()>>> (panicking.rs:552)
==3871==    by 0x464DF7B: catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<global_hotkey::platform_impl::platform::{impl#0}::new::{closure_env#0}, ()>>, ()> (panic.rs:359)
==3871==    by 0x464DF7B: std::thread::Builder::spawn_unchecked_::{{closure}} (mod.rs:557)
==3871==    by 0x4631F7E: core::ops::function::FnOnce::call_once{{vtable.shim}} (function.rs:250)
==3871==    by 0x4B3625A: call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> (boxed.rs:1966)
==3871==    by 0x4B3625A: call_once<(), alloc::boxed::Box<dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>, alloc::alloc::Global> (boxed.rs:1966)
==3871==    by 0x4B3625A: std::sys::pal::unix::thread::Thread::new::thread_start (thread.rs:109)
==3871==    by 0xDE677EA: start_thread (pthread_create.c:448)
==3871==  Address 0xe0 is not stack'd, malloc'd or (recently) free'd
==3871==
==3871==
==3871== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==3871==  Access not within mapped region at address 0xE0
==3871==    at 0xDFE9464: XDefaultRootWindow (Macros.c:52)
==3871==    by 0x463C2B2: global_hotkey::platform_impl::platform::events_processor (mod.rs:192)
==3871==    by 0x463B7F2: global_hotkey::platform_impl::platform::GlobalHotKeyManager::new::{{closure}} (mod.rs:31)
==3871==    by 0x4630062: std::sys::backtrace::__rust_begin_short_backtrace (backtrace.rs:152)
==3871==    by 0x464E1A2: std::thread::Builder::spawn_unchecked_::{{closure}}::{{closure}} (mod.rs:559)
==3871==    by 0x4630F20: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once (unwind_safe.rs:272)
==3871==    by 0x46302FF: std::panicking::try::do_call (panicking.rs:589)
==3871==    by 0x465064A: __rust_try (in /home/user/git/dioxus-example/target/debug/dioxus-example)
==3871==    by 0x464DF7B: try<(), core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<global_hotkey::platform_impl::platform::{impl#0}::new::{closure_env#0}, ()>>> (panicking.rs:552)
==3871==    by 0x464DF7B: catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<global_hotkey::platform_impl::platform::{impl#0}::new::{closure_env#0}, ()>>, ()> (panic.rs:359)
==3871==    by 0x464DF7B: std::thread::Builder::spawn_unchecked_::{{closure}} (mod.rs:557)
==3871==    by 0x4631F7E: core::ops::function::FnOnce::call_once{{vtable.shim}} (function.rs:250)
==3871==    by 0x4B3625A: call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> (boxed.rs:1966)
==3871==    by 0x4B3625A: call_once<(), alloc::boxed::Box<dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>, alloc::alloc::Global> (boxed.rs:1966)
==3871==    by 0x4B3625A: std::sys::pal::unix::thread::Thread::new::thread_start (thread.rs:109)
==3871==    by 0xDE677EA: start_thread (pthread_create.c:448)
==3871==  If you believe this happened as a result of a stack
==3871==  overflow in your program's main thread (unlikely but
==3871==  possible), you can try to increase the size of the
==3871==  main thread stack using the --main-stacksize= flag.
==3871==  The main thread stack size used in this run was 8388608.
==3871==
==3871== HEAP SUMMARY:
==3871==     in use at exit: 1,812,768 bytes in 20,096 blocks
==3871==   total heap usage: 169,485 allocs, 149,389 frees, 13,303,692 bytes allocated
==3871==
==3871== LEAK SUMMARY:
==3871==    definitely lost: 0 bytes in 0 blocks
==3871==    indirectly lost: 0 bytes in 0 blocks
==3871==      possibly lost: 48,787 bytes in 1,071 blocks
==3871==    still reachable: 1,684,709 bytes in 18,302 blocks
==3871==         suppressed: 0 bytes in 0 blocks
==3871== Rerun with --leak-check=full to see details of leaked memory
==3871==
==3871== For lists of detected and suppressed errors, rerun with: -s
==3871== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 0 from 0)
fish: Job 1, 'DEBUGINFOD_URLS=https://debugin…' terminated by signal SIGSEGV (Address boundary error)

[maya-ashley0]

Running with the GDK_BACKEND=wayland environment variable set seems to have no effect

[leo030303]

I've been running into this issue too when trying to get Dioxus to run on Wayland in a Flatpak, did some testing and I think its due to the global_hotkey dependency in dioxus_desktop, if you remove that it runs fine without xwayland, global_hotkey doesn't support wayland and it doesn't appear to be planned tauri-apps/global-hotkey#28 I think I'll try put in a pull request to them to make it fail gracefully if DISPLAY isn't set