Uncaught RuntimeError: unreachable

[PabloBuchu]

After opening the cloud project and hitting tab to open searcher I am getting RuntimeError: unreachable in the console.

The project seems to work fine though.
It was the 2nd project opened in the session meaning the dashboard dropped previous Enso reference and created new one. Maybe it's due to this issue? #6505

cc @farmaazon @wdanilo @somebody1234

[somebody1234]

don't think i can repro unfortunately... the downloads might be too slow to be able to repro it.

this seems to be the line mentioned in the error:

enso/app/gui/view/graph-editor/src/lib.rs

Line 1096 in 86432b5

match axis.binary_search_by(|t| t.partial_cmp(&pos).unwrap()) {

a bit weird though as partial_cmp should only return None for floats when NaN is involved (?!)? so maybe it really is memory corruption

the code was last changed 3 years ago so not sure how likely it is to be a bug in the code

[farmaazon]

Having some Nans here is not entirely crazy, but it's hard to say where is the issue.

[Frizi]

The unreachable error is definitely caused by rust panic, and in of itself can be ignored. So it is likely a rogue NaN issue.

The axis is guaranteed to not contain any NaNs, because it is always kept sorted after each recompute. That sort would fail if there were any.

        sorted_xs.sort_unstable_by(|a, b| a.partial_cmp(b).unwrap());
        sorted_ys.sort_unstable_by(|a, b| a.partial_cmp(b).unwrap());

Which means the pos argument must be NaN for this to fail.

The axis_close_to function is used in a few places. Since hitting tab creates a new node, it is likely the code path involving new_node_position function call that fails:

enso/app/gui/view/graph-editor/src/new_node_position.rs

Lines 69 to 70 in 7e6a919

	let pos = on_ray(graph_editor, screen_center, Vector2(0.0, -1.0)).unwrap();
	magnet_alignment(graph_editor, pos, HorizontallyAndVertically)

I'm not too familiar with this algorithm, but did a quick scan of what's going on there anyway. I found that on_ray internally uses OrderedFloat when performing any comparisons, which means it will likely not fail in the presence of NaNs, allowing them to be passed into magnet_alignment. That then eventually passes the position to axis_close_to without any modifications, which causes a panic.

I can't find any obvious places where a NaN could be created within on_ray itself. It would definitely return a NaN though if passed screen_center happens to be NaN already. That It is a good place to start debugging it If anyone is able to reproduce it.

[wdanilo]

@Frizi thanks for the investigation. It seems that someone needs to just print their values to console and investigate where the NaNs are created and why. Fixing the source is the first step, but the fix should also contain some code preventing it from crashing even if NaNs occur.

[farmaazon]

but the fix should also contain some code preventing it from crashing even if NaNs occur.

I think we should use OrderedFloat or something similar instead of unwrapping.

[hubertp]

Uncaught (in promise) RuntimeError: unreachable
    at __rg_oom (pkg-opt.wasm:0x20d9554)
    at __rust_alloc_error_handler (pkg-opt.wasm:0x20e11d9)
    at alloc::alloc::handle_alloc_error::rt_error::h81daab63a51f18b0 (pkg-opt.wasm:0x20e3bce)
    at alloc::alloc::handle_alloc_error::h724d9ce32b41bdb0 (pkg-opt.wasm:0x20e3bc2)
    at hashbrown::raw::Fallibility::alloc_err::hac56deb9e035bdb0 (pkg-opt.wasm:0x20d49c2)
    at hashbrown::raw::RawTable<T,A>::reserve_rehash::hbb6aeec93c8874be (pkg-opt.wasm:0xc43d54)
    at hashbrown::raw::RawTable<T,A>::insert::h0b0a9282fb108104 (pkg-opt.wasm:0x17282c4)
    at ide_view_graph_editor::builtin::visualization::native::text_visualization::grid_cache::GridCache<T>::add_item::hea7d6a8e547283ce (pkg-opt.wasm:0x1898742)
    at <enso_frp::stream::WeakNode<Def> as enso_frp::stream::WeakEventConsumer<T>>::on_event_if_exists::he0a67ebf8625b97a (pkg-opt.wasm:0x128f8bb)
    at <enso_frp::stream::WeakNode<Def> as enso_frp::stream::WeakEventConsumer<T>>::on_event_if_exists::hcebd7b085828d0a7 (pkg-opt.wasm:0xaf8dcb)
    at <enso_frp::stream::OwnedStream<Out> as enso_frp::stream::EventEmitter>::emit_event::he1ad4c1861193edf (pkg-opt.wasm:0xc050b3)
    at <enso_frp::stream::WeakNode<Def> as enso_frp::stream::WeakEventConsumer<T>>::on_event_if_exists::h2ebbd73d9e15e5f0 (pkg-opt.wasm:0x1709d58)
    at <enso_frp::stream::OwnedStream<Out> as enso_frp::stream::EventEmitter>::emit_event::he1ad4c1861193edf (pkg-opt.wasm:0xc050b3)
    at <enso_frp::stream::WeakNode<Def> as enso_frp::stream::WeakEventConsumer<T>>::on_event_if_exists::hf4c924d140d8d671 (pkg-opt.wasm:0x1697717)
    at <enso_frp::stream::OwnedStream<Out> as enso_frp::stream::EventEmitter>::emit_event::h0834216cae92cecb (pkg-opt.wasm:0xd472d2)
    at enso_frp::nodes::<impl enso_frp::stream::WeakNode<enso_frp::nodes::SourceData<Out>>>::emit::hb2bcd689f4d1781a (pkg-opt.wasm:0x1da0d57)
    at <enso_frp::stream::WeakNode<Def> as enso_frp::stream::WeakEventConsumer<T>>::on_event_if_exists::ha1505055da1b70d7 (pkg-opt.wasm:0x1a410b2)
    at <enso_frp::stream::OwnedStream<Out> as enso_frp::stream::EventEmitter>::emit_event::h0834216cae92cecb (pkg-opt.wasm:0xd472d2)
    at <enso_frp::stream::WeakNode<Def> as enso_frp::stream::WeakEventConsumer<T>>::on_event_if_exists::hd3da4882c69afb66 (pkg-opt.wasm:0x1619489)
    at <enso_frp::stream::WeakNode<Def> as enso_frp::stream::WeakEventConsumer<T>>::on_event_if_exists::h6591ce7aacd94b32 (pkg-opt.wasm:0xc02324)
    at <enso_frp::stream::OwnedStream<Out> as enso_frp::stream::EventEmitter>::emit_event::hb4c9fcb4e623ab7b (pkg-opt.wasm:0xd179b1)
    at <enso_frp::stream::WeakNode<Def> as enso_frp::stream::WeakEventConsumer<T>>::on_event_if_exists::h734ca0b6db5920de (pkg-opt.wasm:0x1d61127)
    at <enso_frp::stream::OwnedStream<Out> as enso_frp::stream::EventEmitter>::emit_event::hb4c9fcb4e623ab7b (pkg-opt.wasm:0xd179b1)
    at enso_frp::nodes::<impl enso_frp::stream::WeakNode<enso_frp::nodes::SourceData<Out>>>::emit::h4aff3afa977b3a63 (pkg-opt.wasm:0x1e55372)
    at enso_prelude::channel::process_stream_with_handle::{{closure}}::h5d315c3f726370d7 (pkg-opt.wasm:0x6ff6c2)
    at futures_util::stream::stream::StreamExt::poll_next_unpin::hd5cdf71362d04e41 (pkg-opt.wasm:0x1027662)
    at futures_executor::local_pool::LocalPool::poll_pool::h7ce81f29ccaebc5f (pkg-opt.wasm:0x1f46ffa)
    at std::thread::local::LocalKey<T>::with::h4a6abba7ccc7bacd (pkg-opt.wasm:0x1d86709)
    at futures_executor::local_pool::LocalPool::run_until_stalled::h25d91c1db5b97c4e (pkg-opt.wasm:0x1f6d0db)
    at <alloc::boxed::Box<F,A> as core::ops::function::FnMut<Args>>::call_mut::h6de2aa7aaaeaab99 (pkg-opt.wasm:0x1faab6f)
    at alloc::vec::Vec<T,A>::retain_mut::haffbc1f3a45f6f28 (pkg-opt.wasm:0x15c42c6)
    at <enso_callback::Registry<dyn core::ops::function::FnMut<(T1,)>+Output = ()> as enso_callback::traits::RegistryRunner1>::run_all::h16c963e470113c33 (pkg-opt.wasm:0x148ff63)
    at core::ops::function::FnOnce::call_once{{vtable.shim}}::h25add263b958d432 (pkg-opt.wasm:0x1e8a894)
    at enso_callback::Registry<F>::run_once_impl::h7f2241b9d9086ac8 (pkg-opt.wasm:0x11505ab)
    at <enso_callback::Registry<dyn core::ops::function::FnOnce<()>+Output = ()> as enso_callback::traits::RegistryRunner0>::run_all::h56bb07efb2430239 (pkg-opt.wasm:0x20e681c)
    at enso_frp::microtasks::SchedulerData::run_all::h9556a12f55b8c1c5 (pkg-opt.wasm:0x146dbd8)
    at enso_frp::microtasks::Scheduler::new::{{closure}}::{{closure}}::h3c9a8723b73c4a5c (pkg-opt.wasm:0x1fd8fff)
    at <dyn core::ops::function::FnMut<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::h9aba2225acfb79ee (pkg-opt.wasm:0x20d632a)
    at __wbg_adapter_92 (eval at <anonymous> (index.ts:296:37), <anonymous>:16987:8)
    at real (eval at <anonymous> (index.ts:296:37), <anonymous>:16907:14)

I'm guessing this is a duplicate, right?

For reference, reproducible on this project all the time for me:
Unnamed_42.zip

Although it kind of feels like a regression because it worked a few days ago.

[somebody1234]

@hubertp from a cursory glance it seems like the root cause is different? seems to be an oom caused by GridCache if i'm reading it correctly...
not sure if anyone would know which commit may have caused this though - you might want to bisect to try and find the commit responsible?

[hubertp]

OK, reported as #6952

[farmaazon]

Not relevant to GUI2 (no panics on Nan-s there)