-
-
Notifications
You must be signed in to change notification settings - Fork 449
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
Strings not freed on runtime components #1215
Comments
edit: I was corrected. Correct me if I'm wrong but I believe the point of the You can create a component at runtime with a runtime-known size, though I'm not familiar with the C++ API, so I only know of the |
@copygirl not quite, you can actually create runtime components, according to this example: This is quite useful for interoperating with scripting, or allowing the user to create components with scripting, which is what I am doing. With the following excerpt, you will see that the size of this component is 24. auto comp = ecs.component("mycomp");
comp.member(flecs::String, "text"); // 8 bytes
comp.member(flecs::U32, "some_number"); // 4 bytes
comp.member(flecs::Bool, "the_bool"); // 4 bytes
comp.member(flecs::U64, "big_uint"); // 8 bytes
std::cout << "size=" << comp.get<flecs::Component>()->size << std::endl; Note that once a component has an entity that uses the component, no further calls to
You have to take into account there are hooks/observers watching So yes, it is possible to create runtime components from scratch, as well as add reflection information to existing c++ structs. This is incredibly powerful :-) My problem is that members of type |
Alright, I stand corrected.
Does the type guarantee a lifetime for the string that's exactly as long as the component's? Because a string could be allocated with the lifetime of the program, come from static program memory, or be reused for multiple components, in which case automatic freeing would not be what you want. I'm unsure if it can be used on a runtime component, nor if it's the right choice, but I wonder if an |
The reason I think this is a bug is that the API that allows you to write a string via reflection does in fact free the previous string that may be already there. This means that the lifetime management of the string living inside the component instance is not the user's responsibility. So, in the typical example: auto comp = ecs.component("mycomp");
comp.member(flecs::String, "text");
flecs::entity e = ecs.entity();
e.add(comp);
void *ptr = e.get_mut(comp);
flecs::cursor cur(ecs, comp, ptr);
cur.push();
cur.member("text");
cur.set_string("hola");
cur.pop(); When you do If you then do the following: cur.push();
cur.member("text");
cur.set_string("adiós");
cur.pop(); the pointer to "hola" would be freed and then replaced with a new pointer to a copy of "adiós". The relevant code is here.
Using the cursor API you cannot set the pointer directly. When you set a string, it copies your string and keeps ownership of that pointer. Therefore, the meta addon is managing the memory related to strings, it is just not freeing it once the component instance is destroyed: I was expecting that it would iterate all fields with a cursor and free all non-primitive types and opaques. |
Yep, this is a known current limitation of runtime components. What needs to happen is that the meta addon needs to register a generic destructor for freeing runtime components. This is not very difficult to do, I'll try to take a look at this asap. |
@SanderMertens ; I wrote the following code, I am sure it is not perfect but the idea here is to iterate the type with a cursor, find all strings and then free them up: void default_dtor(void *ptr, int32_t count, const ecs_type_info_t *type_info) {
// The following code walks the ops structure, and sets all values to null, which destroys all strings
// I ignore "count" for now, I guess I'd have to repeat the below `count` times and advancing `ptr` by the component size each iteration.
ecs_world_t *world = (ecs_world_t *) type_info->hooks.ctx;
ecs_meta_cursor_t cursor = ecs_meta_cursor(world, type_info->component, ptr);
for (ecs_entity_t f = ecs_meta_get_type(&cursor); f;) {
ecs_meta_scope_t *scope = &cursor.scope[cursor.depth];
ecs_meta_type_op_t *op = &scope->ops[scope->op_cur];
if (op->kind == EcsOpPush) {
ecs_meta_push(&cursor);
f = ecs_meta_get_type(&cursor);
continue;
}
if (op->kind == EcsOpPop) {
ecs_meta_pop(&cursor);
if (cursor.depth != 0)
ecs_meta_next(&cursor);
f = ecs_meta_get_type(&cursor);
continue;
}
if (f == flecs::String) {
ecs_meta_set_null(&cursor); // free the string.
}
ecs_meta_next(&cursor);
}
} Then, what I am doing is to set this as the destructor for all the runtime types I create: if (component.has<RuntimeComponent>()) {
const flecs::type_hooks_t *h = ecs_get_hooks_id(component.world().c_ptr(), component);
assert(h)
flecs::type_hooks_t hooks = *h;
if (hooks.dtor == nullptr) {
hooks.ctx = component.world().c_ptr(); // store the world as user context so we can use it in destructor.
hooks.dtor = default_dtor; // point to destructor function detailed above
ecs_set_hooks_id(component.world().c_ptr(), component, &hooks);
}
} One thing I am lacking that would be nice for the destructor signature is to have it receive a world pointer, because I am occupying the user context for that, and perhaps other people would need it for their stuff. Should we also do It feels a bit hacky, but it works. Is there a better way? We can evolve this conversation until we get to a PR. Thanks! |
UPDATE: as part of migrating to v4, I simplified this fix. Here is the updated code: // Recursively search for strings in the type and free them
void free_strings(ecs_world_t *ecs, void *ptr, const EcsTypeSerializer *ser) {
// Get a pointer to the first element in the array
ecs_meta_type_op_t *ops = ecs_vec_first_t(&ser->ops, ecs_meta_type_op_t);
// get the number of opcodes:
int32_t op_count = ecs_vec_count(&ser->ops);
for (int i = 0; i < op_count; i++) {
ecs_meta_type_op_t &op = ops[i];
switch (op.kind) {
case EcsOpOpaque: {
const EcsOpaque *ct = ecs_get(ecs, op.type, EcsOpaque);
ecs_assert(ct != NULL, ECS_INTERNAL_ERROR, NULL);
const EcsTypeSerializer *ser2 = ecs_get(ecs, ct->as_type, EcsTypeSerializer);
free_strings(ecs, ECS_OFFSET(ptr, op.offset), ser2);
} break;
case EcsOpString: {
char **ppstring = (char **) (ECS_OFFSET(ptr, op.offset));
ecs_os_free(*ppstring);
*ppstring = nullptr;
} break;
default: {
} break;
}
}
}
void default_dtor(void *ptr, int32_t count, const ecs_type_info_t *type_info) {
// default destructor for components created at runtime
// there is a bug whereupon strings in runtime components are not freed:
// https://github.com/SanderMertens/flecs/issues/1215
ecs_world_t *world = (ecs_world_t *) type_info->hooks.ctx;
const EcsTypeSerializer *ser =
(EcsTypeSerializer *) ecs_get_id(world, type_info->component, ecs_id(EcsTypeSerializer));
for (int i = 0; i < count; i++) {
free_strings(world, ECS_OFFSET(ptr, i * type_info->size), ser);
}
}
|
Looks promising! Few notes:
|
Thanks :-) I will take a look at this after your feedback to consider other types. The above is mostly a hack. Incidentally, we need to add default implementations for at least move assign and copy assign hooks. I just ran into this after debugging a double-free (I believe that by default, when there is no move-assign, components are copied via memcpy, therefore string pointers are copied then freed twice by mistake). |
Not fixed yet! |
Ah, GitHub automatically closed it because the world_t pointer PR got merged! |
Describe the bug
When creating runtime components that contain strings, these strings are not freed on entity destruction, resulting in a memory leak.
To Reproduce
This snippet sets up a hook on the
free()
function used by Flecs and prints a message if the pointer to the string we are expecting to be deleted is actually deleted. This deletion never happens, thus there is a memory leak.I also could not find in the code (
addons/meta
) anything that automatically frees up resources related to runtime components.Expected behavior
When an entity that contains a runtime component is destroyed, all items in that runtime struct should be destroyed.
The text was updated successfully, but these errors were encountered: