[bug] dangling connections are never removed and eventually max out

thenbe commented 4 months ago

Describe the bug

I have an mjpg server running in the background. I play the video stream in my tauri app like so:

<img src="http://localhost:8080/stream" />

The stream runs fine. If I refresh (right click > reload) the page, the stream also continues to play fine. However, I now start to see that there are 2 active client connections on my server logs. If I refresh again, it goes up to 3. This continues until it "maxes out" at 6 connections. After which, my app no longer tries to connect my mjpeg server. At that point I need to quit and restart my tauri app to make things work again.

I've narrowed the issue down to: once my tauri app opens up a connection to my mjpeg server, there's no way it'll let go. Even hacks like randomizing the src attribute do not help (connections are just added and are never removed).

Reproduction

Start an mjpeg server, (eg. ustreamer)

ustreamer \
    --device=/dev/video0 \
    --host=127.0.0.1 \
    --port=8080 \
    --format=MJPEG \
    --persistent

Stream some dummy video

# generate the test video
ffmpeg -f lavfi -i testsrc=duration=10:size=1920x1080:rate=30 -loglevel error -y /tmp/vid.mjpg

# pipe it to our virtual device (on loop)
ffmpeg \
    -stream_loop -1 \
    -re \
    -i /tmp/vid.mjpg \
    -vf "format=yuv420p" \
    -vcodec mjpeg \
    -f v4l2 \
    /dev/video0

Start a tauri app with this element

<img src="http://localhost:8080/stream" />

Reload (right click > reload) the tauri app several times.
Observe the ustreamer logs showing the number of active increasing and never dropping.
After reloading 7 times, observe that the stream completely stops working. At this point, there's no way to get the tauri app to render the stream. We need to quit the tauri app.
Observe that this behavior is not reproducible when running your app in a browser (firefox, chrome, etc)

Versions

$ npx tauri info
[⚠] Environment
    - OS: NixOS 24.5.0 X64
    ✔ webkit2gtk-4.1: 2.42.5
    ✔ rsvg2: 2.57.1
    ✔ rustc: 1.78.0-nightly (a4472498d 2024-02-15)
    ✔ cargo: 1.78.0-nightly (fc1d58fd0 2024-02-09)
    ⚠ rustup: not installed!
      If you have rust installed some other way, we recommend uninstalling it
      then use rustup instead. Visit https://rustup.rs/
    ⚠ Rust toolchain: couldn't be detected!
      Maybe you don't have rustup installed? if so, Visit https://rustup.rs/
    - node: 20.11.1
    - pnpm: 8.15.1
    - npm: 10.2.4

[-] Packages
    - tauri [RUST]: 2.0.0-beta.2
    - tauri-build [RUST]: 2.0.0-beta.1
    - wry [RUST]: 0.35.2
    - tao [RUST]: 0.25.0
    - @tauri-apps/api [NPM]: 2.0.0-beta.1
    - @tauri-apps/cli [NPM]: 2.0.0-beta.2

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:3000/
    - framework: Svelte
    - bundler: Vite

$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.77, NixOS, 24.05 (Uakari), 24.05.20240216.5863c27`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(root): `"home-manager, nixos"`
 - nixpkgs: `/etc/nix/inputs/nixpkgs`

Stack trace

No response

canxin121 commented 4 months ago

Maybe it has something to do with my issue. #8916

FabianLars commented 4 months ago

Maybe it has something to do with my issue. https://github.com/tauri-apps/tauri/issues/8916

Unlikely, we have no control over how the webview connects to the server there at all so i assume this is yet another upstream webkitgtk issue. Either that, or something like https://github.com/tauri-apps/wry/issues/590 (which also may or may not be an upstream issue though i think this would be on us).

tauri-apps / tauri