tauri: [bug] Event emit crashes app with high call rate

Describe the bug

Too many calls to tauri::Window::emit in a short amount of time causes the app to crash.

Reproduction

Initial testing was conducted using a minimal reproduction with the upload plugin and downloading the latest daily Blender build. It was later narrowed down to be related to the event system and an event flooder was created which exhibits the same behaviour on a more consistent basis with 100,000 or more calls.

Expected behavior

No response

Platform and versions

[✔] Environment
    - OS: Windows 10.0.22000 X64
    ✔ WebView2: 119.0.2151.44
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.72.0 (5680fa18f 2023-08-23)
    ✔ cargo: 1.72.0 (103a7ff2e 2023-08-15)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 20.9.0
    - pnpm: 8.10.2
    - yarn: 1.22.19
    - npm: 10.1.0

[-] Packages
    - tauri [RUST]: 1.5.2
    - tauri-build [RUST]: 1.5.0
    - wry [RUST]: 0.24.4
    - tao [RUST]: 0.16.5
    - @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/
    - bundler: Vite

Stack trace

No response

Additional context

This issue was previously discussed on Discord. @FabianLars demonstrated a mitigation for the upload plugin by reducing the frequency of calls to emit on the download-throttled-events branch which led to reduced crashing but didn’t eliminate it entirely. The impact this issue has on the upload plugin would be reduced in environments with slow drives and fast networks as there is more time between messages and fewer overall messages.

About this issue

  • Original URL
  • State: open
  • Created 8 months ago
  • Reactions: 9
  • Comments: 30 (15 by maintainers)

Commits related to this issue

Most upvoted comments

Just here to say I noticed this too when upgrading from tauri 1.4.1 to 1.5.2

The workaround I’m using is basically reverting to 1.4.1

@JJeris I limited the events per second. I didn’t like the idea of throttling using an iterator as the total number of events scales with file size and we currently don’t know the root cause. I also contemplated using invoke instead to fetch a counter, but didn’t in the end.

No, this issue doesn’t seem to be specific to that plugin so i left the workaround branch untouched. Maybe i’ll merge it into the main branches as a temporary solution since it’s typically the plugin with the most events.

Yes, that’s why I wasn’t sure what everyone was talking about, because the issue always happens when the events are emitted and listened for too quickly, so it isn’t specific for this case.

No, this issue doesn’t seem to be specific to that plugin so i left the workaround branch untouched. Maybe i’ll merge it into the main branches as a temporary solution since it’s typically the plugin with the most events.