`wasm_bindgen`-caused web crash when using more than 2GiB of RAM

rerun-io / rerun

Visualize streams of multimodal data. Fast, easy to use, and simple to integrate. Built in Rust using egui.

https://rerun.io/

Apache License 2.0

6.39k stars 312 forks source link

`wasm_bindgen`-caused web crash when using more than 2GiB of RAM #1513

Closed Wumpf closed 1 year ago

Wumpf commented 1 year ago

We're getting fairly weird crashes when sending many log messages per frame.

Most reliable repro for this is running the nyud example on the web from a an rrd file. cargo run -p rerun --features web_viewer --release -- --web-viewer ../nyud.rrd

We spent already quite a bit of time investigating this, some findings so far:

what we log doesn't seem to matter. The crash typically shows a callstack pointing to DynamicResourcePool::alloc, but whether we log the desc there doesn't seem to matter
there is some suspicious looking log spam sometimes
A bisection yielded #1382, but CpuGpuReadBelt itself doesn't seem to be to blame, but the logs added there
- andreas/safe-read-write-belt has an experiment with a slower but safe write belt and it didn't make a difference either

Link to internal Slack conversation

We should not log as much by default in the browser though! Once log mesages are limited to info, the crash disappears.

emilk commented 1 year ago

We had this problem when we first switched to the wgpu renderer. Back then the solution was to lessen the wgpu log spam.

emilk commented 1 year ago

I think we should:

Write our own log backend for the web, which uses console.debug,console.warn for warn etc
Switch from tracing to log overall. tracing is so complicated, and we don't use any of the complexity. See for instance https://github.com/tokio-rs/tracing/issues/2499 - this seems a lot more doable with just the log crate.
- Easy with https://docs.rs/tracing/latest/tracing/#crate-feature-flags

jleibs commented 1 year ago

This crash still happening on Windows / Chrome.

re_viewer.js:250 wasm-bindgen: imported JS function that was not marked as `catch` threw an error: Failed to execute 'decode' on 'TextDecoder': The encoded data was not valid.

Stack:
TypeError: Failed to execute 'decode' on 'TextDecoder': The encoded data was not valid.
    at getStringFromWasm0 (http://127.0.0.1:9090/re_viewer.js:52:30)
    at http://127.0.0.1:9090/re_viewer.js:473:23
    at logError (http://127.0.0.1:9090/re_viewer.js:241:18)
    at imports.wbg.__wbg_debug_5724a17d71ee30be (http://127.0.0.1:9090/re_viewer.js:472:68)
    at <re_log::log_web::WebLogger as log::Log>::log::h7307dab4feba4ab0 (wasm://wasm/03926f7e:wasm-function[4494]:0x69a04b)
    at tracing::__macro_support::__tracing_log::h3fa7e5b1e5362b6e (wasm://wasm/03926f7e:wasm-function[9095]:0x88c9f1)
    at re_viewer::misc::caches::tensor_image_cache::ImageCache::purge_memory::h15409aaa79f7b3b5 (wasm://wasm/03926f7e:wasm-function[2333]:0x4f1d88)
    at <re_viewer::app::App as eframe::epi::App>::update::hb91cf160d1948745 (wasm://wasm/03926f7e:wasm-function[429]:0x3b098)
    at <re_viewer::remote_viewer_app::RemoteViewerApp as eframe::epi::App>::update::hd7e42035066700e2 (wasm://wasm/03926f7e:wasm-function[16884]:0x9b5fb7)
    at eframe::web::backend::AppRunner::logic::h50d1ef9f43177454 (wasm://wasm/03926f7e:wasm-function[1877]:0x46b10b)

Wumpf commented 1 year ago

Not confirmed directly yet on this version, but it seems highly likely this was fixed in https://github.com/rustwasm/wasm-bindgen/pull/3310