Sounds like the module’s buffer manager is just a lazy pointer; maybe the dealloc function never gets called because the code path exits early, or the smart pointer is accidentally reset. Check for mismatched new/delete, missing release in exception handlers, or static objects that never get cleaned up. If it’s an old codebase, the “destroy” routine might be hidden behind a macro that gets omitted in a release build. The simplest sanity check is to run it under Valgrind or similar and see what allocation chain shows up when the leak occurs. If that’s still a mystery, look at where the buffer is stored—if it’s a raw array in a singleton, the destructor never runs. That’s usually the culprit.

Good plan, just make sure the cleanup isn’t itself leaking—double‑check that the destructor still runs even after you add the manual routine. If you hit another mystery, let me know.

Sounds like a solid safety net. Just keep an eye out for that flag being set twice in a row—that’s a good sign of hidden recursion. Ping me if the leak decides to take a second wind.