Skip to content

Conversation

@Watermelon914
Copy link
Contributor

You can currently create a memory leak by adding a component to an entity and then removing the component or deleting the entity. In most cases, this will leak memory as drop is never called.

This PR fixes that by introducing the changes made to flecs to fix that, and adjusting the dtors so that drop is properly called. Relevant PR can be found here, as well as explanations on why this memory leak is happening: SanderMertens/flecs#1874

This has a breaking change:

  1. flecs::With can no longer be used as it causes the target components to not be initialized when ecs_emplace_id is used. This is a known bug: https://discord.com/channels/633826290415435777/939683115109072926/1439766559781294201
  2. Introduces actually dropping most components when they are supposed to be deleted. This could maybe cause bugs based on code that relies on erroneous behaviour.
  3. The on_replace hook requires a Default constructor to be set. This is because setting on_replace means that ecs_emplace_id can't be used as flecs internals needs to guarantee a call to the hook if the value is replaced. Theoretically we could get around this limitation if the rust bindings takes more control over the process and handles the on_replace hook call itself.

Set behaviour is drastically modified for components with no default constructor: ecs_emplace_id is used instead of ecs_cpp_set, as the latter requires the use of a ctor, otherwise you can get a drop on uninitialized data leading to UB. This is likely from the assumption that anything that has a dtor, probably also has a ctor in C++. This is not always the case in rust, which means we need special handling. It's possible that this could be fixed on the flecs side of things, but it's not trivial to do so since it's a problem that happens during deferral.

Ultimately, this PR introduces dropping on move_dtor, which is called whenever the destination target is constructed memory and is being memcpy'd into. There could still possibly be bugs or memory leaks I haven't spotted yet, but this should fix the most egregious case and I've added some unit tests to showcase that.

@Watermelon914 Watermelon914 marked this pull request as draft December 9, 2025 13:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant