unsafe precondition violation in DispatcherMainThreadContext #10001
Comments
nicolaiunrein
added
status: needs triage
I am unable to reproduce this with rust 1.78, please take some time to make a minimal repro so we can fix this asap |
|
No repro but seems like I ran into a similar one related to Rust 1.78: Workaround: tauri info UPDATE: Not recommending the workaround anymore, it can interfere with code that's trying to test whether we're in debug mode or not. |
|
@betamos Did you capture a backtrace? It seems the issue you are seeing is caused by a different assertion. I figured out mine is caused by moving the above struct (with an internal Rc) to a different thread which is UB because Rc is not Send and dropping it there. The assertion I hit is that the strong count does not equal 0 which IMO can only happen in unsafe code. The question is how to re-create a situation where the Rc can escape the thread it was created on. I have some vague ideas but need to find the time to investigate. In summary we are calling a method with a callback closure (FnMut) where we reference a |
|
I reproduced the error. I suspected that the problem was with the emit function, so I executed the following code, and it replicated the problem tauri info When I adjusted the number of repetitions downward, the error reported became a WebViewc error. code: error: |
|
I must admit I don't really understand why this is happening, both stack traces you posted (though the panic happens in different branches) are crashing bc of an rc increment from a different thread, which, should not really ever happen I don't think? Unless webview2 started delivering events to random threads within the threadpool |
|
I tried but didn't get a proper backtrace for some reason, sorry. Can confirm I'm also using emit, quite a lot. |
maybe is I emit in setup？ |
And now I Test the emit with sleep(), this panic no happen again |
To be clear the code you're showing is not from the setup closure, but a task spawned from it. But no, for me it's not in setup but from window event handlers (some irrelevant details omitted): let mut app = tauri::Builder::default()
.invoke_handler(tauri::generate_handler![
get_clipboard_files,
config::set_background,
config::get_config
])
.setup(|app| {
let window_builder =
WindowBuilder::new(app, "main", tauri::WindowUrl::App("index.html".into()));
let window = window_builder.build().unwrap();
let app_handle = app.handle();
let app_handle_2 = app_handle.clone();
window.listen("ui", move |e| {
app_handle_2
.state::<agent::Input>()
.send(e.payload().unwrap())
.expect("channel failure");
});
window.once("init", move |_| {
// Read program output
tauri::async_runtime::spawn(async move {
let agent_result = output
.run()
.try_for_each(|str| async {
app_handle
.emit_to("main", "agent", str)
.map_err(|err| anyhow!("error emitting to window: {:?}", err))
})
.await;
if let Err(ref err) = agent_result {
_ = app_handle.emit_to("main", "agent", agent::EXIT_MSG);
eprintln!("pld failed: {:?}", err);
} else {
eprintln!("pld complete");
}
});
});
Ok(())
})
.on_window_event(move |win_e| { ... })
.menu(menu::get_menu(&ctx.package_info().name))
.on_menu_event(|e| {
eprintln!("menu event: {:?}", e);
})
.build(ctx)
.expect("error while running tauri application"); |
Thanks！ |
|
Started getting the same issue (I think). I'll be honest, rust scares me so I have no clue what any of this means but I'm here to help solve it asap. This is for an app that I am releasing in 2 weeks so the timing is very rough. I recently upgraded rust and some dependencies to latest versions, and don't remember this happening before that in the last 2 months of development. It will crash my app at random, sometimes 20 seconds after launch, sometimes 10 minutes, and anywhere inbetween. I haven't detected one single action I'm taking that does it. |
|
@DaveyUS Don't be scared, the rust compiler just tries to help us find problems in our code in debug mode. To clarify: It is an annoying problem to have these panics during development. But 1. They are debug asserts, just make sure to compile your code in release mode and the panics should go away. 2. The problems have potentially been there for a very long time. It is only now with rust 1.78 that we get these panics during development. Please have a look here at: https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html |
|
I was mostly joking about being scared, but your comment did put me at ease. I really appreciate the quick response! Seems like crashing the entire app to alert you that there could maybe be an issue is a pretty weird decision by the people developing rust. A friendlier experience would be to silently alert or have an alert that requires input when you go to build. I'm sure there's more to it that I don't understand though. Oh well, in the meantime I guess ill downgrade since I was having no problems on the previous version. Cheers! |
|
I have the same error, It's look like this |
Describe the bug
We are experiencing
Unsafe Precondition Violations during development. I could identify the check being triggered while cloningDispatcherMainThreadContext. Specifically while cloning the innerglobal_shortcut_managerwhich is anRc.DispatcherMainThreadContextimplsSendandSyncmanually with this safety explanation:// SAFETY: we ensure this type is only used on the main thread.. It seems that our code somehow managed to find a way to violate the rules.Possible solution
I forked this repo and managed to fix the issue by replacing the
Rcwith anArc. I don't know how big of an impact this has on performance. If you decide that this is the way to go I am happy to create a PR.Note:
This issue was introduced by rust 1.78.0 and should only happen in debug builds.
See: https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html#asserting-unsafe-preconditions
Reproduction
Unfortunately I don't have the time to create a minimal reproducable example but wanted you know anyway.
Expected behavior
Condition check to pass
Full
tauri infooutputStack trace
Additional context
The text was updated successfully, but these errors were encountered: