-
-
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
User-mode data execution prevention (DEP) violation when loading Dynamic Plugins #13073
Comments
cz-kaga
added
C-Bug
An unexpected or incorrect behavior
S-Needs-Triage
This issue needs to be labelled
labels
Apr 23, 2024
BD103
added
P-Crash
A sudden unexpected crash
A-App
Bevy apps and plugins
and removed
S-Needs-Triage
This issue needs to be labelled
labels
Apr 23, 2024
Bevy's dynamic plugin interface is almost certainly unsound, and I think this may be one such case. You may find #11969 interesting in this regard. Other bits of code that are related include |
github-merge-queue bot
pushed a commit
that referenced
this issue
May 20, 2024
# Objective - The current implementation for dynamic plugins is unsound. Please see #11969 for background and justification. - Closes #11969 and closes #13073. ## Solution - Deprecate all dynamic plugin items for Bevy 0.14, with plans to remove them for Bevy 0.15. ## Discussion One thing I want to make clear is that I'm not opposed to dynamic plugins _in general_. I think they can be handy, especially for DLC and modding, but I think the current system is the wrong approach. It's too much of a footgun for the meager benefit is provides. --- ## Changelog - Deprecated the current dynamic plugin system. - Dynamic plugins will be removed in Bevy 0.15. For now you can continue using them by marking your code with `#[allow(deprecated)]`. ## Migration Guide If possible, remove all usage of dynamic plugins. ```rust // Old #[derive(DynamicPlugin)] pub struct MyPlugin; App::new() .load_plugin("path/to/plugin") .run(); // New pub struct MyPlugin; App::new() .add_plugins(MyPlugin) .run(); ``` If you are unable to do that, you may temporarily silence the deprecation warnings. ```rust #[allow(deprecated)] ``` Please note that the current dynamic plugin system will be removed by the next major Bevy release, so you will have to migrate eventually. You may be interested in these safer alternatives: - [Bevy Assets - Scripting]: Scripting and modding libraries for Bevy - [Bevy Assets - Development tools]: Hot reloading and other development functionality - [`stabby`]: Stable Rust ABI [Bevy Assets - Scripting]: https://bevyengine.org/assets/#scripting [Bevy Assets - Development tools]: https://bevyengine.org/assets/#development-tools [`stabby`]: https://github.com/ZettaScaleLabs/stabby
salvadorcarvalhinho
pushed a commit
to salvadorcarvalhinho/bevy
that referenced
this issue
May 25, 2024
# Objective - The current implementation for dynamic plugins is unsound. Please see bevyengine#11969 for background and justification. - Closes bevyengine#11969 and closes bevyengine#13073. ## Solution - Deprecate all dynamic plugin items for Bevy 0.14, with plans to remove them for Bevy 0.15. ## Discussion One thing I want to make clear is that I'm not opposed to dynamic plugins _in general_. I think they can be handy, especially for DLC and modding, but I think the current system is the wrong approach. It's too much of a footgun for the meager benefit is provides. --- ## Changelog - Deprecated the current dynamic plugin system. - Dynamic plugins will be removed in Bevy 0.15. For now you can continue using them by marking your code with `#[allow(deprecated)]`. ## Migration Guide If possible, remove all usage of dynamic plugins. ```rust // Old #[derive(DynamicPlugin)] pub struct MyPlugin; App::new() .load_plugin("path/to/plugin") .run(); // New pub struct MyPlugin; App::new() .add_plugins(MyPlugin) .run(); ``` If you are unable to do that, you may temporarily silence the deprecation warnings. ```rust #[allow(deprecated)] ``` Please note that the current dynamic plugin system will be removed by the next major Bevy release, so you will have to migrate eventually. You may be interested in these safer alternatives: - [Bevy Assets - Scripting]: Scripting and modding libraries for Bevy - [Bevy Assets - Development tools]: Hot reloading and other development functionality - [`stabby`]: Stable Rust ABI [Bevy Assets - Scripting]: https://bevyengine.org/assets/#scripting [Bevy Assets - Development tools]: https://bevyengine.org/assets/#development-tools [`stabby`]: https://github.com/ZettaScaleLabs/stabby
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bevy version
0.13.2
[Optional] Relevant system information
OS: Windows 11 Pro for Workstations - 23H2 - 22631.3447
CPU: AMD Ryzen 7 4800H with Radeon Graphics 2.90 GHz
GPU: NVIDIA GeForce GTX 1650Ti for Laptop
RAM: 64GB
Rust Version: rustc 1.77.2 (25ef9e3d8 2024-04-09)
Cargo Version: cargo 1.77.2 (e52e36006 2024-03-26)
What you did
I am tring to test whether Bevy can share component type throuth different dynamic plugins(i.e. System in one dylib can detect component spawned by System in another dylib).
So I create three crates inside the main project. One defines Components, Others depend this static lib and run Systems. In main.rs of this project, I enable bevy's "bevy_dynamic_plugin" feature then invoke load_plugin()
What went wrong
Whether test success or fail, dynamic_plugin should built successfully, but I encountered
Exception: Exception 0xc0000005 encountered at address 0x000000: User-mode data execution prevention (DEP) violation at location 0x00000000
and then bevy crashed.Additional information
I debug the application several times. I'm sure that dlls are successfully loaded.
The last step before exception is as follows:
then, it crashes:
The top of trace stack is:
It appears that the address of
self
is 0x0 or 0x4 or many other address nearby 0x0, but actuallyself
has its own address. What happend when app callsplugin.build(self)
?I switched lib type to cdylib, but it makes nonsense.
The content of dll is quite simple(This problem exists whether these lines are commented or not ):
same to main.rs
My friend helped me checked dll content with IDA, he says the dll files I used are completely normal.
Debugger of RustRover gives me assembly code, I don't know whether it can help.
As I reruned the app, I found that addresses in vtable of dyn Plugin changed unnormally.
The text was updated successfully, but these errors were encountered: