[bug] *intermittent* GTK may only be used from the main thread #11312
Comments
zakhenry
added
status: needs triage
|
Hmm, not sure if the stacktrace alone is enough tbh (it's not for me, but maybe for someone here who can actually read those lol). In the spawned tauri app, are you spawning your own tokio runtime (maybe via btw, i assume |
|
Sorry yes I mean the spawn method of #[tokio::main]
async fn main() -> Result<(), Box<dyn Error>> {
let config = CliArguments::parse().try_into()?;
tauri::async_runtime::set(tokio::runtime::Handle::current());
// run my tauri app and a bunch of other things with tokio
} |
|
I got a similar error in a similar one (macos v 13.2). But interestingly, the error does not appear on other macOS (v 15 & v 14). I mean I tried the app with 6 different Macs and the error only appeared only one machine. I don't have an idea how can I reproduce the error though :( tokio-runtime-worker exc bad aacess (SIGSEGV) |
|
Just adding some information that it doesn't seem to depend on custom tokio runtimes. I am consistently getting this error in my app on launch. It's not spawning a runtime manually, and disabling any thread::spawn calls didn't seem to help. Then I created a test app using If I find a small consistent repro I will share it. edit: platform is Linux (Ubuntu 24.10) by the way. |
|
For me the following small application based on the template triggers it approximately 50% of the time: I am running it as |
|
@FabioGNR amazing that is a nice small repro thanks, are you able to share the stack trace so I can see if it matches mine (i.e. likely same root cause). I'm on macos so won't encounter the same issue unless I try set it up with docker I guess. fwiw I'm also executing the app with |
|
I'm also doing an The tauri app is spawned in a tokio::task and I've made sure to call |
|
@zakhenry of course, here's the stacktrace: |
|
Thanks @FabioGNR yep the two stacktraces look the same at a certain point (from |
|
I don't know if this crash could happend for different reasons since you crash in tauri 2.0.2, but my app works fine in 2.0.3. |
|
tried to update to 2.1 and got the error. I still gotta use 2.0.3. Could this problem be linked to 3cb73d0 ? |
|
No, I reverted back to a working version 2.0.0-rc and haven't tried since. I'll share an update if I found something. |
|
Took another look at this, the call to GTK is done from the MainContext thread, so that's not the issue. But it appears
Adding a call to |
|
@FabioGNR this seems very promising and might be worth raising the PR anyway? If I'm interpreting you correctly the call `tao`` makes to initialise GTK does not actually eagerly call gtk::init(), but lazily calls it later when gtk is subsequently interacted with, and for some cases this call might not be coming from the main thread, causing this issue? If that is right then in seems pretty sensible to ensure it is called from the main thread before calling |
Having looked further into it, the call to If I understand correctly gtk signals first call the custom handlers and then the default, which would mean it's marked as initialized before it actually is. Still, this shouldn't affect calls to Either way I'm stuck at this point because I'm having trouble debugging the internal of gtk-rs and gtk itself. |
Describe the bug
I'm afraid this is a particularly hard one to reproduce, but hopefully the stack trace helps someone point me in the right direction.
I have a tauri app that I am launching in integration tests with
tokio::process::spawn(my app is launched as a cli tool). So as the app is running as a sub process, it is running in the main thread and everything should be fine.The issue arises within the integration test when I am making some calls to the web frontend and sometimes (roughly 50% of the time) I get the following error:
The remaining 50% of the time I have several back and forth calls with the UI and the test completes successfully.
Reproduction
I can't provide this at this time, hoping the stack trace is enough..
Expected behavior
Should be able to consistently run tauri as a subprocess without encountering GTK main thread issues.
Full
tauri infooutputStack trace
Additional context
No response
The text was updated successfully, but these errors were encountered: