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

[Wumpf]

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 CpuWriteGpuReadBelt for fast frame by frame memory transfers #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]

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

[emilk]

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 Dynamically add more log layers at run-time tokio-rs/tracing#2499 - this seems a lot more doable with just the log crate.
  • Easy with https://docs.rs/tracing/latest/tracing/#crate-feature-flags

[jleibs]

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]

Not confirmed directly yet on this version, but it seems highly likely this was fixed in rustwasm/wasm-bindgen#3310