Damaged mesh, it's back.

[John-Nagle]

Old report: #480

It's back, post-arcanization. Discussed on Discord, but needed an issue.

Here are bad and good versions of the same scene. Same program, run twice.

• Someone else has been able to reproduce this (see Rend3 discord) so it's not a machine problem.
• This is the problem that repeated a few days ago and was cleared by a reboot.
• My experience is that this either appears at startup or it doesn't appear at all. So I suspect un-initialized data.
• Happens about one run in 10.
• Symptom is one or more vertices of a legit object being totally out of place.

[John-Nagle]

was followed by this panic:

06:00:11 [ERROR] =========> Panic assertion failed: (i == 0 || self.free_ranges[i - 1].end < range.start) &&
(i >= self.free_ranges.len() || range.end < self.free_ranges[i].start) at file /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/range-alloc-0.1.3/src/lib.rs, line 133 in thread main.
Backtrace:
libcommon::common::commonutils::catch_panic::{{closure}}
at /home/john/projects/sl/SL-test-viewer/libcommon/src/common/commonutils.rs:215:25
range_alloc::RangeAllocator::free_range
at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/range-alloc-0.1.3/src/lib.rs:133:9
rend3::managers::mesh::MeshManager::remove
at /home/john/.cargo/git/checkouts/rend3-issue570-7a55d7cece9b9b17/bafdc3b/rend3/src/managers/mesh.rs:217:13
rend3::renderer::eval::evaluate_instructions
at /home/john/.cargo/git/checkouts/rend3-issue570-7a55d7cece9b9b17/bafdc3b/rend3/src/renderer/eval.rs:137:21
rend3::renderer::Renderer::evaluate_instructions
at /home/john/.cargo/git/checkouts/rend3-issue570-7a55d7cece9b9b17/bafdc3b/rend3/src/renderer/mod.rs:482:9
<sharpview::AppUi as rend3_framework::App>::handle_redraw
at /home/john/projects/sl/SL-test-viewer/sharpview/src/main.rs:665:31
rend3_framework::async_start::{{closure}}::{{closure}}
at /home/john/.cargo/git/checkouts/rend3-issue570-7a55d7cece9b9b17/bafdc3b/rend3-framework/src/lib.rs:371:17
winit::platform_impl::platform::x11::EventLoop::single_iteration
at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/linux/x11/mod.rs:608:17
winit::platform_impl::platform::x11::EventLoop::poll_events_with_timeout
at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/linux/x11/mod.rs:547:9
winit::platform_impl::platform::x11::EventLoop::pump_events
at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.10/src/platform_impl/linux/x11/mod.rs:453:13

[cwfitzgerald]

I'm going to optimistically close this, now that a large chunk of the nasty manipulation code is gone.

[John-Nagle]

Sadly, it's not gone in the new no-gpu-culling version (rev = "4709529")

Damaged mesh, then a panic in MeshManager::remove.

(Performance is better. Will discuss that separately.)

05:32:03 [ERROR] =========> Panic assertion failed: (i == 0 || self.free_ranges[i - 1].end < range.start) &&
(i >= self.free_ranges.len() || range.end < self.free_ranges[i].start) at file /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/range-alloc-0.1.3/src/lib.rs, line 133 in thread main.
Backtrace:
libcommon::common::commonutils::catch_panic::{{closure}}
at /home/john/projects/sl/SL-test-viewer/libcommon/src/common/commonutils.rs:360:25
range_alloc::RangeAllocator::free_range
at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/range-alloc-0.1.3/src/lib.rs:133:9
rend3::managers::mesh::MeshManager::remove
at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/4709529/rend3/src/managers/mesh.rs:205:13
rend3::renderer::eval::evaluate_instructions
at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/4709529/rend3/src/renderer/eval.rs:120:21
rend3::renderer::Renderer::evaluate_instructions
at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/4709529/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:699:31
rend3_framework::async_start::{{closure}}::{{closure}}
at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/4709529/rend3-framework/src/lib.rs:344:17
winit::platform_impl::platform::x11::EventLoop::single_iteration
at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.14/src/platform_impl/linux/x11/mod.rs:602:17
winit::platform_impl::platform::x11::EventLoop::poll_events_with_timeout

[John-Nagle]

Another panic. This one may be unrelated. Happened after hours of running successfully.

11:15:17 [ERROR] =========> Panic called `Option::unwrap()` on a `None` value at file /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/4709529/rend3/src/managers/object.rs, line 139 in thread main.
Backtrace:
 libcommon::common::commonutils::catch_panic::{{closure}}
             at /home/john/projects/sl/SL-test-viewer/libcommon/src/common/commonutils.rs:360:25
 rend3::managers::object::ObjectManager::add
 rend3::renderer::eval::evaluate_instructions
             at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/4709529/rend3/src/renderer/eval.rs:74:21
 rend3::renderer::Renderer::evaluate_instructions
             at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/4709529/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:699:31
 rend3_framework::async_start::{{closure}}::{{closure}}
             at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/4709529/rend3-framework/src/lib.rs:344:17
 winit::platform_impl::platform::x11::EventLoop<T>::single_iteration
             at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.14/src/platform_impl/linux/x11/mod.rs:602:17
 winit::platform_impl::platform::x11::EventLoop<T>::poll_events_with_timeout
             at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.14/src/platform_impl/linux/x11/mod.rs:541:9
 winit::platform_impl::platform::x11::EventLoop<T>::pump_events
             at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.14/src/platform_impl/linux/x11/mod.rs:447:13
 winit::platform_impl::platform::x11::EventLoop<T>::run_on_demand
             at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.14/src/platform_impl/linux/x11/mod.rs:408:19

[John-Nagle]

I've had the crash in "add" again. I think that one may be associated with running out of GPU resources. Rend3 now returns an error code when the GPU is full, and I recover from that. Recovery works by scheduling a reduction in LOD, which will regenerate objects at lower rez. This works but does mean that ramming into the rendering stack's resource limits happens in normal operation. Something may break under that stress. If that error was returned slightly before hitting the absolute limit, that would be fine,.

The "remove" crash is associated with garbage triangles appearing, and consistently occurs in the first minute or two of operation. If it doesn't happen at startup, it's often possible to run for an hour.

[John-Nagle]

Panic called `Option::unwrap()` on a `None` value at file /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/d088a84/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:360:25
 rend3::managers::object::ObjectManager::add
 rend3::renderer::eval::evaluate_instructions
             at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/d088a84/rend3/src/renderer/eval.rs:72:21
 rend3::renderer::Renderer::evaluate_instructions
             at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/d088a84/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:699:31
 rend3_framework::async_start::{{closure}}::{{closure}}
             at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/d088a84/rend3-framework/src/lib.rs:344:17
 winit::platform_impl::platform::x11::EventLoop<T>::single_iteration
             at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/linux/x11/mod.rs:602:17
 winit::platform_impl::platform::x11::EventLoop<T>::poll_events_with_timeout
             at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/linux/x11/mod.rs:541:9
 winit::platform_impl::platform::x11::EventLoop<T>::pump_events
             at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/linux/x11/mod.rs:447:13
 winit::platform_impl::platform::x11::EventLoop<T>::run_on_demand
             at /home/john/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/linux/x11/mod.rs:408:19

This is after fixing the problem in the memory allocator (Bug #546). That one hasn't repeated. But this old one has. No jagged out of place vertices, though.

That line of code is calling a function indirected through a reference. I'll look into what it's doing. The line of code is

(mesh, &{}[..])