egui
egui copied to clipboard
eframe X11 crash after using thread spawn
Describe the bug
Random crash 1 out of 4 times when spawning a thread with thread::spawn
on X11
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
rustyboi: ../../src/xcb_io.c:269: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
To Reproduce Steps to reproduce the behavior:
- Create a simple
eframe
app - Build it, it shoul start just fine
- Add
thread::spawn
withloop{}
- Build it again, it should start randomly crashing on start
Expected behavior N/A
Screenshots
Desktop (please complete the following information):
- OS: Pop OS + KDE Plasma X11 (gdm3)
- Browser: N/A
I think this is a problem that should be reported to winit
Have same on Arch Linux x64 (Manjaro), X11, Intel HD 3000, mesa 21.3.7-2. This error is there 8 months as minimum.
Anyone wants to dig into this? Likely culprits include glutin
, glow
, winit
, or a combination of the three.
I have this in Cargo.toml: eframe = { version = "0.17.0", default-features = false, features = ["default_fonts", "egui_glow"] } I see no way to set glutin...
same issue. i suspect there's an issue somewhere inside glutin, i tried (ubuntu/latest mesa driver [from obiaf repo]) using both fltk and sdl with glow... even winit with egui wgpu backend, everything's working fine. see: https://github.com/rust-windowing/glutin/issues/1034
Just as a data point I just upgraded to a much faster machine (from circa 2009 4 core i7 to 16 core ryzen), and my egui app does this every time. I have yet to see it run :-( On the slower machine, it never happened.
Seems like a lot of people have problem with this, yet nobody has tried to reproduce it using pure glutin
and/or glow
without eframe
?
Try https://github.com/grovesNL/glow/tree/main/examples/hello with the glutin backend and spawn a thread and see if you can reproduce. Maybe try RUST_BACKTRACE=1
and see if you get a callstack.
I can't test https://github.com/grovesNL/glow/tree/main/examples/hello : thread 'main' panicked at '0:1(10): error: GLSL 4.10 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.40, 1.50, 3.30, 1.00 ES, and 3.00 ES.
But I have same error on https://github.com/emilk/egui/blob/0.17.0/egui_glow/examples/pure_glow.rs and https://github.com/emilk/egui/blob/0.17.0/egui_glium/examples/pure_glium.rs
I tried glow hello w/glutin backend. The same error occurs. There is no backtrace, just core dump.
I was able to get something of a backtrace from the core dump:
Thread 1 (Thread 0x7f1fd4ff2800 (LWP 24822)): #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=139774694205440) at pthread_kill.c:44 #1 __pthread_kill_internal (signo=6, threadid=139774694205440) at pthread_kill.c:80 #2 __GI___pthread_kill (threadid=139774694205440, signo=signo@entry=6) at pthread_kill.c:91 #3 0x00007f1fd5037476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 --Type <RET> for more, q to quit, c to continue without paging-- #4 0x00007f1fd501d7b7 in __GI_abort () at abort.c:79 #5 0x00007f1fd501d6db in __assert_fail_base (fmt=0x7f1fd51d1770 "%s%s%s:%u: %s%sAssertion
%s' failed.\n%n", assertion=0x7f1fd4f549e8 "!xcb_xlib_threads_sequence_lost", file=0x7f1fd4f54620 "../../src/xcb_io.c", line=269, function=
I should note I didn't modify hello at all, just built debug, and ran it. It ran as expected once out of about 20 runs.
I am using i3. It runs more often if I run it in a subdivided screen so the initial window is smaller. Maybe 1/3 of the time it works this way.
I am using a 3rd generation pentium, just putting it there for context
@ambihelical please open an issue in the glutin repository!
@emilk Hmmm, it turned out my new system did not have correctly set up nvidia drivers and was using software rendering. After I fixed, this I no longer get the crash. Possibly I was seeing a different bug than everyone else? I will continue to monitor things, if it occurs I'll do that.
@emilk the root cause of this problem is that glutin can't tolerate any gpu without vsync support (i have no idea why the reason behind this, intentionally or just a poorly written bug?), and the simple solution to this problem is that just ignore swap_interval only if the gpu has no swap interval extension (vsync) support as mentioned on this PR: https://github.com/rust-windowing/glutin/pull/1387 or we can just simply remove this (needless error message) line inside glutin. but nobody seems to care and not being merged.
and here's the proof that this kind of bug can be fixed and this issue can be closed.
the PR: https://github.com/rust-windowing/glutin/pull/1387 finally being merged a while ago, waiting for glutin > v0.28.0 release
I finally installed an Ubuntu VM and ran into this exact issue ^^ probably because of using a software renderer like @ambihelical suspected.
for glutin > v0.28.0 or patched glutin, turn off vsync.
// When compiling natively:
fn main() {
// Log to stdout (if you run with `RUST_LOG=debug`).
// tracing_subscriber::fmt::init();
let mut options = eframe::NativeOptions {
// Let's show off that we support transparent windows
transparent: true,
drag_and_drop_support: true,
..Default::default()
};
// like so
options.vsync = false;
eframe::run_native(
"egui demo app",
options,
Box::new(|cc| Box::new(egui_demo_lib::WrapApp::new(cc))),
);
}
the error will be gone.
@emilk exactly, even in software render egui runs quite fast.
I just turned off vsync for test, but this doubles the CPU load for me. Not really on option therefore.
@sourcebox of course, the main purpose of vsync is... to stabilize the frame rate and it also reduce the CPU consumtion on HW with GPU acceleration, but when it comes down to software render that's different story.
@Ar37-rs I do some frame limiting on my own now, but even with vsync disabled I get the error on my old notebook which is only supporting OpenGL ES2. But I have some multithreading going on, so this might be the cause. On my newer notebook which basically the same software configuration, everything is running fine even with vsync enabled.
@sourcebox i'm using mesa OpenGL 4.5 llvmpipe software render > 20.x.x on ubuntu vm intel skylake, even if i use the latest patched glutin from rust-windowing github repo (not the current version of glutin which 0.28.0) my egui app suddenly crashing with vsync enabled, so i have to disable vsync in my case in other to work.
Maybe your GPU doesn't support the latest OpenGL version? I just tried looking into this bug by playing with the hello example, and I got the same issue with that example. However, when I added this line below line 35, and ran it using cargo run --features=glutin
:
.with_gl(glutin::GlRequest::Specific(glutin::Api::OpenGl, (4, 1)))
I didn't have this issue any more.
I also experienced a similar issue with another app/game, but I was able to fix that issue for myself by telling it what OpenGL version to use when creating the OpenGL context.
Is some of your problems solved with https://github.com/emilk/egui/pull/1693 ?
Unfortunately not.
i have the same error, using linux mint 20.3 with KDE plasma as the desktop, eframe & egui 0.19.0
This shouldn't happen with the wgpu backend (?)