-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stack overflow despawning entity with handle component to "large" asset #1892
Comments
It might be worth noting that replacing the array in the struct with a |
Can repro with MacOS 11.2.3 (intel), rustc 1.51.0 Magic number was 58144. |
Hmm I'm guessing that the issue is that we're moving something allocated on the heap (the |
This feels more like a "programming / language / OS constraint" problem than a Bevy problem. |
Allows render resources to move data to the heap by boxing them. I did this as a workaround to #1892, but it seems like it'd be useful regardless. If not, feel free to close this PR.
Maybe it would be best just to document it as a limitation then? This issue can be avoided by just boxing large fields or using heap-allocated types like |
Allows render resources to move data to the heap by boxing them. I did this as a workaround to bevyengine#1892, but it seems like it'd be useful regardless. If not, feel free to close this PR.
Fixes bevyengine#1892 The following code is a cut down version of the issue, and crashes the same way: ```rust enum AssetLifecycleEvent <T> { Create(T), Free } fn main() { let (sender, _receiver) = crossbeam_channel::unbounded(); sender.send(AssetLifecycleEvent::<[u32; 32000]>::Free).unwrap(); } ``` - We're creating a channel that need to be able to hold `AssetLifecycleEvent::Create(T)` which has the size of our type `T` - The two variants of the enums have a very different size By keeping `T` boxed while sending through the channel, it doesn't crash
Bevy version
0.5.0
Operating system & version
Windows 10
What you did
I've included a small project to reproduce the issue.
TypeUuid
for it. This will be your asset..add_asset::<T>()
to register it as an asset.Handle<T>
component to that entity. TheHandle<T>
should come from adding an instance of the asset to aResMut<Assets<T>>
. Check repro for example.I don't know if the size needed to stack overflow is system-dependent. For my system, 32KB was more than enough (win10, stable-x86_64-pc-windows-msvc, 16GB RAM).
What you expected to happen
No stack overflow. I expected the asset to be freed once I despawned the entity because it was the only entity with a strong handle to that asset as a component.
What actually happened
It stack overflowed after the entity was despawned.
Additional information
The text was updated successfully, but these errors were encountered: