dfa/onepass.rs: index out of bounds

What version of regex are you using?

regex: 1.10.2
regex-automata: 0.4.3

Describe the bug at a high level.

A one-off panic on this line under wasm32-unknown-unknown:

regex/regex-automata/src/dfa/onepass.rs

Line 845 in 61242b1

let existing_dfa_id = self.nfa_to_dfa_id[nfa_id];

panicked at index.crates.io-6f17d22bba15001f/regex-automata-0.4.3/src/dfa/onepass.rs:845:49:
index out of bounds: the len is 0 but the index is 0
    at N.t.wbg.__wbg_new_3a66822ed076951c (https://tably.com/xxx:21:28770)
    at js_sys::Error::new::ha28ef1a62e15080a:0xb3430f
    at std::panicking::rust_panic_with_hook::h5350537741e0bf00:0xae2d67
    at std::panicking::begin_panic_handler::{{closure}}::h8fcf1faeeecee4ac:0xb1830e
    at std::sys_common::backtrace::__rust_end_short_backtrace::h1009326c6818b847:0xb42c42
    at rust_begin_unwind:0xb34b20
    at core::panicking::panic_fmt::h51b759f5003b86a3:0xb3569a
    at core::panicking::panic_bounds_check::h9c2960824679ca14:0xb26eae
    at regex_automata::dfa::onepass::InternalBuilder::add_dfa_state_for_nfa_state::h0908395130475902:0xa77613
    at regex_automata::meta::strategy::new::h41660dfe5adfe834:0x5239a
    at regex_automata::meta::regex::Builder::build::h1b42c4716e5c9433:0x1eb43a
    at regex::regex::string::Regex::new::hd0f0a111f8a3560b:0x46a4f7
    at leptos_components::svg::raw_svg::h90ef59e5d763ff40:0x4f88d6
    at frontend::main::{{closure}}::hf814089493d2f278:0x1bc655
    at frontend::main::h489e819a0ec9a8a2:0x181c60
    at main:0xb42dfc
    at z (https://tably.com/xxx:21:52885)
    at X (https://tably.com/xxx:21:53847)

What are the steps to reproduce the behavior?

Our Wasm app contains this line:

let regex_id = Regex::new(r#"id="([^"]+)""#).unwrap();

It's successfully run many thousands of times; this specific version of the Wasm app has successfully run in about 500 browsers. However, one browser panicked with the above stack trace:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Safari/537.36 HeyTapBrowser/45.10.5.4.1

They left the site after this and we have no further information that I think could be helpful.

I see two potential differences in environment that could have caused this: allocation failure or browser bug. I don't know enough about the former under Wasm to rule it out. And I wouldn't be surprised if it was the latter. Have since updated the versions and will post if we get any clarity.

I don't know enough about the former under Wasm to rule it out.

An allocation failure should result in a panic/abort, no?

Unfortunately, without reproduction steps, I'm not sure this is actionable.

An allocation failure should result in a panic/abort, no?

Assuming no use of try_reserve and similar, then yes in theory. In practise rustwasm has some rough edges.

Do feel free to close as unactionable, I opened this primarily for if anyone else happens to bump into this heisenbug.