Open John-Nagle opened 4 months ago
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
I'm going to optimistically close this, now that a large chunk of the nasty manipulation code is gone.
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
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
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.
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, &{}[..])
Old report: https://github.com/BVE-Reborn/rend3/issues/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.