Avoid memory leaks

There are several modules with intermittent leaks reported by ASan and Valgrind. Run a targeted sweep: reproduce the leak with the unit tests, identify the allocation stack traces, replace the leaking allocations with owning smart pointers or ensure proper delete in destructors, and re-run tests to prove no leak remains. Push fixes to hotfix/leak-fix, notify QA, and close bug 4821 by Thursday.

Before I hand this to QA, make the leak fixes easy to verify: list the specific allocations you changed, show the before/after ASan or Valgrind snippets, summarize why each leak happened and how the fix ensures deterministic cleanup. Highlight any remaining risky code paths that still use bare new or manual resource management.

Valgrind shows leaked objects allocated in our manager but the stack trace goes through a third-party library. I maintain the networking module and Jim owns the library integration; I'm worried the leak is either ours for failing to free callbacks or theirs for not releasing internal buffers. I cannot tell from the trace who must free what. What's the likely diagnosis and the fastest next step to prove ownership and fix it?

Across multiple releases we keep spending days chasing leaks caused by inconsistent ownership of callbacks and resource pools. I lose time in repro, blame passes between teams, and credibility suffers. What systemic habit or small tooling change will stop this recurring waste, and how do I enforce it in PRs and test suites?