mirror of
https://github.com/bevyengine/bevy
synced 2024-09-20 06:22:01 +00:00
9a123cd3a7
# Objective - Fixes #10820. ## Solution - Check that the asset ID to be inserted is still being managed. - Since this route is only used by `AssetServer`-tracked handles, if the `infos` map no longer contains the asset ID, all handles must have been dropped. In this case, since nobody can be watching for the result, we're safe to bail out. This avoids the panic when inserting the asset, because when the handles are dropped, its slot in `Assets<A>` is poisoned. - Someone may be waiting for a labelled asset rather than the main asset, these are handled with separate calls to `process_asset_load`, so shouldn't cause any issues. - Removed the workaround keeping asset info alive after the handle has died, since we should no longer be trying to operate on any assets once their handles have been dropped. ## Testing - I added a `break` in `handle_internal_asset_events` (`crates/bevy_asset/src/server/mod.rs` on line 1152). I don't believe this should affect correctness, only efficiency, since it is effectively only allowing one asset event to be handled per frame. This causes examples like `animated_fox` to produce the issue fairly frequently. - I wrote a small program which called `AssetServer::reload` and could trigger it too. --- ## Changelog - Fixed an issue which could cause a panic when loading an asset which was no longer referenced. --- ## Remaining Work ~This needs more testing. I don't yet have a complete project that reliably crashes without changes to bevy.~ We have at least one vote of confidence so far from @Testare who had a project broken by this bug. @cart, (sorry for the ping), I believe you added the code which delays `remove_dropped`. Was there any other reason `track_assets` needed to keep the dropped assets alive? |
||
|---|---|---|
| .. | ||
| macros | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
Bevy Asset
