Where's the unwrap() call?

help
1

Fixing a crate. Getting an unwrap panic. Takes about half an hour of running a GUI program to get this intermittent error, so it has to be run in release mode. Thus some inlines don't appear in the backtrace.

Backtrace says it's here at

let mesh = &mesh_manager_guard[**mesh];

There's no explicit unwrap call inside the function ObjectManager::add which contains that line. The backtrace shows control in that function, so this is the right place to look.

So, what implicit operation could be failing? **mesh means deferencing the contents of an ObjectMeshKind::Static, which is a MeshHandle, which is a ResourceHandle<Mesh>.
ResourceHandle has an implementation of Deref, so there's an implicit function call.

But the Deref called is here, and it has no .unwrap() call. So the first Deref should not cause that error.

The result of the first Deref is a RawResourceHandle. That doesn't have a Deref function defined.

So I haven't been able to find which unwrap call is causing the problem. What else might be called implicitly? Advice?

Actual backtrace below:

Panic called `Option::unwrap()` on a `None` value at file /home/john/.cargo/git/checkouts/rend3-hp-02d0af34d7a82ce7/fd670d4/rend3/src/managers/object.rs, line 136 in thread main.
Backtrace:
libcommon::common::commonutils::catch_panic::{{closure}}
at /home/john/projects/sl/SL-test-viewer/libcommon/src/common/commonutils.rs:389:25
rend3::managers::object::ObjectManager::add
rend3::renderer::eval::evaluate_instructions
at /home/john/.cargo/git/checkouts/rend3-hp-02d0af34d7a82ce7/fd670d4/rend3/src/renderer/eval.rs:72:21
rend3::renderer::Renderer::evaluate_instructions
at /home/john/.cargo/git/checkouts/rend3-hp-02d0af34d7a82ce7/fd670d4/rend3/src/renderer/mod.rs:422:9
<sharpview::AppUi as rend3_framework::App>::handle_redraw
at /home/john/projects/sl/SL-test-viewer/sharpview/src/main.rs:723:31
rend3_framework::async_start::{{closure}}::{{closure}}
at /home/john/.cargo/git/checkouts/rend3-hp-02d0af34d7a82ce7/fd670d4/rend3-framework/src/lib.rs:345:17
winit::platform_impl::linux::x11::EventLoop::single_iteration
at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.30.7/src/platform_impl/linux/x11/mod.rs:563:17
winit::platform_impl::linux::x11::EventLoop::poll_events_with_timeout
at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.30.7/src/platform_impl/linux/x11/mod.rs:504:9
winit::platform_impl::linux::x11::EventLoop::pump_events
at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.30.7/src/platform_impl/linux/x11/mod.rs:424:13
winit::platform_impl::linux::x11::EventLoop::run_on_demand
at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.30.7/src/platform_impl/linux/x11/mod.rs:385:19
2

I’m guessing the Index call invoked by x[y]. That’s implemented in rend3/src/managers/mesh.rs, with the unwrap here on line 317.

2 Likes
3

Ah, Index. I was looking for Deref, and not thinking about Index.

Changed the .unwrap() to an .expect('msg"), and got the message. Thanks.

4

Just for future reference, so you know where to look first.
Deref is not expected to fail (although it may) whereas Index is expected to panic for out of bounds access.

From the docs for Deref:

This trait’s method should never unexpectedly fail . Deref coercion means the compiler will often insert calls to Deref::deref implicitly. Failure during dereferencing can be extremely confusing when Deref is invoked implicitly. In the majority of uses it should be infallible, though it may be acceptable to panic if the type is misused through programmer error, for example.

From the docs of Index::index:

fn index(&self, index: Idx) -> &Self::Output

Performs the indexing (container[index]) operation.

Panics

May panic if the index is out of bounds.

1 Like
5

It would be nice to mark their reply as the solution, since they solved it for you.

5 Likes
6

you should be able to enable full debug info in release mode, or enable optimizations in debug mode by changing/adding a cargo profile so you can get the full backtrace with inlined functions.

1 Like