Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] npm run tauri dev crashes on saving main.tsx #8183

Open
dyzdyz010 opened this issue Nov 7, 2023 · 12 comments
Open

[bug] npm run tauri dev crashes on saving main.tsx #8183

dyzdyz010 opened this issue Nov 7, 2023 · 12 comments
Labels
status: needs triage This issue needs to triage, applied to new issues type: bug

Comments

@dyzdyz010
Copy link

Describe the bug

I'm creating a multi-window app using Tauri. When I'm in dev I run npm run tauri dev to start the dev environment.

I use rust to create a window in runtime and close the first window. When I'm working on this newly created window, I hit save on frontend's entry main.tsx, the app crashes, and the command exits immediately without any warnings or errors, nothing.

Reproduction

  1. Create a new app using react as frontend
  2. Add create window code in rust and make jump logic
  3. Enter dev env using npm run tauri dev
  4. Save main.tsx file

Expected behavior

Live-load changes to my source code as expected

Platform and versions

[✔] Environment
    - OS: Mac OS 14.0.0 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.73.0 (cc66ad468 2023-10-03)
    ✔ cargo: 1.73.0 (9c4383fb5 2023-08-26)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 18.17.1
    - pnpm: 8.6.6
    - npm: 9.6.7
    - bun: 1.0.7

[-] Packages
    - tauri [RUST]: 1.5.2
    - tauri-build [RUST]: 1.5.0
    - wry [RUST]: 0.24.4
    - tao [RUST]: 0.16.5
    - tauri-cli [RUST]: 1.5.6
    - @tauri-apps/api [NPM]: 1.5.1
    - @tauri-apps/cli [NPM]: 1.5.6

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - framework: React
    - bundler: Vite


### Stack trace

```text
None

Additional context

No response

@dyzdyz010 dyzdyz010 added status: needs triage This issue needs to triage, applied to new issues type: bug labels Nov 7, 2023
@FabianLars
Copy link
Member

Can you share an actual reproduction example (a repo we can look at)? Since there are no warnings/errors i'd suspect a logic error/oversight first.

@kul-sudo
Copy link

Could you please give more context?

@clearlysid
Copy link
Contributor

clearlysid commented Nov 16, 2023

Identified this problem after discussing it with @FabianLars on Discord. The crash isn't React-specific, it affects all frontend frameworks including vanilla.

Here's a minimal repro of the issue in a project bootstrapped by the CTA vanilla template:
https://github.com/clearlysid/tauri-multiwindow-crash-test

  1. Spin up the dev environment for the project yarn tauri dev
  2. The app opens 2 windows. Close window 1.
  3. Make a change in the HTML/CSS/JS of src/second.html.
  4. Your app will crash if you save.

@clearlysid
Copy link
Contributor

Just realized. The order of windows spawned and closed doesn't matter — if you have 2 (or more) windows, close any one of them and proceed to make changes to your frontend, your app WILL crash 😭

@amrbashir
Copy link
Member

This works fine on my Windows machine, I see that the OP was on macOS so I will let someone else test on macOS.

@clearlysid were you also on macOS?

@clearlysid
Copy link
Contributor

Yes, I was on macOS. I can re-check for Windows today and confirm.

@clearlysid
Copy link
Contributor

Sorry I didn't get to update here. Me and a colleague both tried and were not able to reproduce the crash on Windows. Definitely seems like a macOS-only bug 🥲

@clearlysid
Copy link
Contributor

clearlysid commented Jan 20, 2024

Log when running with --verbose terminates with

       Debug [hyper::proto::h1::io] flushed 1426 bytes
       Debug [hyper::proto::h1::conn] read eof
       Debug [hyper::proto::h1::conn] read eof

@clearlysid
Copy link
Contributor

Interestingly adding the following snippet in the Tauri main function fixes the issue, as per this PR

.on_window_event(|event| match event.event() {
     tauri::WindowEvent::CloseRequested { api, .. } => {
     event.window().hide().unwrap();
     api.prevent_close();
}
 _ => {}

@dceddia
Copy link
Contributor

dceddia commented Apr 25, 2024

I think I've been seeing a similar crash, but I only have a single window in my app. I narrowed it down to where it will crash if:

  • a tauri command is started (easier to reproduce if this is a long-running one, e.g. an async one that sleeps)
  • then, while the command is running, cause the browser to reload (modify main.ts or something)
  • when the (now stale!) command finishes, the program will crash when it tries to send its response

Here's a minimal repro: https://github.com/dceddia/tauri-crash-ipc

  • When the app starts, it kicks off a tauri command that will finish in 20 seconds.
  • Within that 20 seconds, modify main.ts and save (causing a reload)
  • When the 20 second command finishes, the app will crash.

I haven't been able to get it to print a stack trace with RUST_BACKTRACE=1 but I did notice I can attach a debugger before it crashes and find the stack that way.

@Palm5
Copy link

Palm5 commented May 14, 2024

I'm having the same problem with a single window. Every time I recompile the front-end (i'm using Angular) and I invoke a particular tauri command it makes the webview freeze, like the invocation is not returning and stays hanging. The backend is not throwing any errors and it doesn't even panic. It seems that making the tauri command async doesn't make the webview freeze at the first call after recompilation, but it will eventually freeze after a couple of calls.

@FabianLars
Copy link
Member

@Palm5 this is unrelated to this issue. Sync commands run on the main thread so are expected to freeze your app if they are running for a long time. The problem with the async command is a bit concerning though so please open a new issue with the code of that command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: needs triage This issue needs to triage, applied to new issues type: bug
Projects
None yet
Development

No branches or pull requests

7 participants