Intermittent crashes due to invalid UTF-8 passed to DOM

[kazcw]

Discord username

No response

What type of issue is this?

Transient – Occuring only once

Is this issue blocking you from using Enso?

• Yes, I can't use Enso because of this issue.

Is this a regression?

• Yes, previous version of Enso did not have this issue.

What issue are you facing?

While creating a node, the application stopped responding to input. There's an error in the web console:

VM12:598439 Uncaught TypeError: Failed to execute 'decode' on 'TextDecoder': The encoded data was not valid.
    at getStringFromWasm0 (eval at <anonymous> (index.js:67:5706), <anonymous>:598439:28)
    at imports.wbg.__wbg_setinnerHTML_32081d8a164e6dc4 (eval at <anonymous> (index.js:67:5706), <anonymous>:599919:33)
    at web_sys::features::gen_Element::Element::set_inner_html::h4c650bd60b84f2d3 (pkg-opt.wasm:0x1cc3c48)
    at ide_view_documentation::Model::display_doc::hb04efac363eb5402 (pkg-opt.wasm:0x15d3f70)
    at <enso_frp::stream::WeakNode<Def> as enso_frp::stream::WeakEventConsumer<T>>::on_event_if_exists::he605228485a4aa0b (pkg-opt.wasm:0x1a12020)
    at <enso_frp::stream::OwnedStream<Out> as enso_frp::stream::EventEmitter>::emit_event::h31eb8fa0b80e0b3c (pkg-opt.wasm:0xba4278)
    at <enso_frp::stream::WeakNode<Def> as enso_frp::stream::WeakEventConsumer<T>>::on_event_if_exists::hc4f7cf32bdbb8165 (pkg-opt.wasm:0x13ff390)
    at <enso_frp::stream::OwnedStream<Out> as enso_frp::stream::EventEmitter>::emit_event::hc3870a0e2c79d9ae (pkg-opt.wasm:0xca99b7)
    at <core::option::Option<T> as enso_prelude::option::OptionOps>::for_each::hdf4eddb55bd2e2ae (pkg-opt.wasm:0x1acf9e7)
    at enso_frp::io::timer::timeout::Timeout::new::{{closure}}::hee901b17f6147e5d (pkg-opt.wasm:0x1beb051)
    at <dyn core::ops::function::FnMut<()>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::h47edd6c521a33284 (pkg-opt.wasm:0x1cbb2ad)
    at __wbg_adapter_80 (eval at <anonymous> (index.js:67:5706), <anonymous>:598656:8)
    at real (eval at <anonymous> (index.js:67:5706), <anonymous>:598588:14)

Expected behaviour

No fatal errors.

How we can reproduce it?

No response

Screenshots or screencasts

No response

Enso Version

f64edd8

Browser or standalone distribution

Standalone distribution

Browser Version or standalone distribution

standalone

Operating System

Linux

Operating System Version

No response

Hardware you are using

No response

[wdanilo]

This is so strange! do you have any idea what could cause it or where in the code it breaks?

[kazcw]

I looked in to it a little. It seems like this error would only occur if ide_view_documentation::Model::display_doc is passing invalid utf-8 to JS through wasm_bindgen in the String(!). Only unsafe code can create a non-utf8 String, and all kinds of UB would ensue. However, the horrorshow crate we are using to generate the HTML String only has one direct usage of unsafe, and it looks sound. So this seems serious but I don't see what could be causing it.

[wdanilo]

Very interesting. Thanks for the investigation @kazcw! Hmm, if this happens again, let's chat more about it.

[jdunkerley]

Removing from project until happens again - at which will be prioritised.

[kazcw]

Just talked with @wdanilo since this has been encountered a second time. Because it's so rare, we have higher priorities in the short term.

When we come back to this:

1. Try to reproduce it reliably by generating HTML and utf8-validating the Strings in a test suite.
2. Run the test suite under UBSan--hopefully the corrupt strings are a product of detectable UB earlier.
3. If not solved with UBSan, look at unsafe code in the stack, try substituting safe code, see if it fixes it.

[kazcw]

Today I just encountered this again. Since Greg has just had the same issue, I am wondering if some recent change has made this more common.

[wdanilo]

Can we for now catch this place and handle it if it happens? It looks like this sets some HTML content so I believe that it would not be application-critical if we catch it then for now.

[kazcw]

Yeah, we can define our own binding for setInnerHTML that uses the wasm-bindgen catch attribute, and use it when sending the documentation to the DOM. I can do it tomorrow morning.

[kazcw]

I have just encountered an instance of this apparently unrelated to documentation--in this case, the invalid string was passed to __wbindgen_string_new during ensogl_text::component::text::TextModel::replace_selections, whereas previous occurrences were in a setInnerHTML call after generating doc HTML.

Full log