`GpuComponentArrayBuffer` panics when two instances leave the array in one frame, or one comes and goes in a frame
Maintainer thường phản hồi trong vòng 2 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 70/100
Hướng nghiên cứu
Start with crates/bevy_render/src/gpu_component_array_buffer.rs, especially update_components and GpuComponentArray::remove; the issue gives two reproductions and the failing assertions or command error. Trace how removals and swap-removal handle multiple entities and components added then removed before the system runs. Done means both reproductions and arbitrary same-frame removal orders complete without panicking.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Bevy version
0.20.0 (crates.io). crates/bevy_render/src/gpu_component_array_buffer.rs on main at
fd9e7609109758a2d9af401345f100be9442e9f6 (2026-10-24) is byte-identical, so main has both bugs.
What went wrong
update_components::<C> (gpu_component_array_buffer.rs:130-220) has two reachable panics.
1. A command to a despawned entity. A removed entity's entry is swap-removed: the last entry moves into the gap,
and a command inserts the moved entity's new MeshTag:
if let Some((displaced_entity, displaced_entity_new_tag)) = component_array.remove(&mut buffer, entity) {
commands.entity(displaced_entity).insert(MeshTag::with_type::<GpuComponentArray<C>>(displaced_entity_new_tag));
}
Sometimes the displaced entity was despawned in the same frame, and its own removal comes later in
RemovedComponents. Then the command fails, and the default error handler panics:
Encountered an error in command `insert<MeshTag>`: Entity despawned: The entity with ID 544v0 is invalid; its index now has generation 1.
Common ways to remove two instances in one frame:
- despawn a parent whose children carry the component (
Childrenislinked_spawn); - despawn a batch of instances, for example on a scene or level change.
Unless the batch happens to go from the highest tag down, this panics.
2. An instance added and removed before the system ran. The component is inserted and then removed (or the entity
despawned) in the same frame, before update_components runs. Its removal is then read from RemovedComponents, but
the entity was never pushed. remove panics:
- in a debug build:
debug_assert!(!self.tag_to_entity.is_empty())(:305) when the array is empty; - otherwise:
.expect("Entity must have been present")(:314).
How to reproduce
use bevy::ecs::query::QueryItem;
use bevy::ecs::system::lifetimeless::Read;
use bevy::prelude::*;
use bevy::render::gpu_component_array_buffer::{GpuComponentArrayBuffer, GpuComponentArrayBufferPlugin};
use bevy::render::storage::ShaderBuffer;
#[derive(Component, Clone, Copy)]
struct Data(u32);
impl GpuComponentArrayBuffer for Data {
type QueryData = Read<Self>;
type QueryFilter = Changed<Self>;
type Out = u32;
fn extract_component(data: QueryItem<'_, '_, Self::QueryData>) -> Option<u32> {
Some(data.0)
}
}
fn app() -> App {
let mut app = App::new();
app.add_plugins((MinimalPlugins, AssetPlugin::default()))
.init_asset::<ShaderBuffer>()
.add_plugins(GpuComponentArrayBufferPlugin::<Data>::default());
app
}
#[test]
fn two_instances_leaving_in_one_frame() {
let mut app = app();
let e: Vec<Entity> = (0..3).map(|i| app.world_mut().spawn(Data(i)).id()).collect();
app.update(); // tags 0, 1, 2
app.world_mut().despawn(e[0]); // its slot is filled with e[2]'s entry, and e[2] is re-tagged by a command...
app.world_mut().despawn(e[2]); // ...but e[2] is gone too
app.update(); // panics: `insert<MeshTag>`: Entity despawned
}
#[test]
fn an_instance_coming_and_going_in_one_frame() {
let mut app = app();
let e = app.world_mut().spawn(Data(0)).id();
app.world_mut().entity_mut(e).remove::<Data>();
app.update(); // panics in `GpuComponentArray::remove`
}
Both tests fail on bevy 0.20.0 (run 2026-10-25, a debug build without Bevy's debug feature, which names the command):
two_instances_leaving_in_one_frame: Encountered an error in command `<Enable the debug feature to see the name>`: Entity despawned: The entity with ID 33v0 is invalid; its index now has generation 1.
an_instance_coming_and_going_in_one_frame: gpu_component_array_buffer.rs:305:9: assertion failed: !self.tag_to_entity.is_empty()
Expected
Any set of entities can lose the component in one frame, in any order, and nothing panics.
- Ngôn ngữ chính
- Rust
- Star
- 49.7k
- Fork
- 5k
- Merge trung bình
- 3 ngày 19 giờ
- Pull request đã merge (30 ngày)
- 134
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của bevyengine/bevy
-
C-Bug S-Needs-Triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
bevyengine/bevy#26536 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Placeholder has no defaultCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởC-Feature S-Needs-Triage
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 62/100
bevyengine/bevy#26532 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
C-Feature S-Needs-Triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
bevyengine/bevy#26500 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
`Selected` should derive ReflectĐang mởC-Feature S-Needs-Triage
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 68/100
bevyengine/bevy#26499 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
`compute_histogram` in auto exposure writes past the end of the 64-bin histogramCó thể đã có người làm @dev-matru đã nhận 3 ngày trước. Đang mởA-Rendering C-Bug D-Straightforward S-Ready-For-Implementation X-Uncontroversial
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
bevyengine/bevy#26479 ·
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của bevyengine/bevy
Issue tương tự
-
bug UI
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
wardian-app/Wardian#1746 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
jlcodes99/cockpit-tools#3125 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
bug user-sprint
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Vondor/KassenSturz#967 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area/ci
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[BUG] Incremental sync warns "no stored highest_uid" on every round for folders with no new mailĐang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
rustmailer/bichon#411 ·