https://svn.boost.org/trac10/ticket/598 <pre class="wiki">While working with boost.python, I've noted that instantiating most specializations of boost::python::extract&lt;&gt; results in MSVC leak reports. My usual tactic for third-party libraries in such cases is to suppress the CRT tracking for the affected code. This is how I deal with the abundant "leaks" from Python due to not calling Py_Finalize(), for example. In this case, though, the allocations are pre-main() and I can't get a suppression hook in ahead of it. I realize that these aren't true leaks, and that there is some reluctance to ferret out such situations at the moment due to the lack of support for Py_Finalize(), but this generates a *lot* of leak reports and makes it very difficult to recognize true leaks. It was actually making me consider not using extract&lt;&gt; at all. I realized that was an overreaction, so instead I added a destructor for struct boost::python::converter::registration that explicitly walks and deletes the singly-linked list nodes contained therein. This resolved my current flurry of extract&lt;&gt;-related leak reports. </pre> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/598 Trac 1.4.3 david_abrahams Sat, 16 Sep 2006 17:05:38 GMT https://svn.boost.org/trac10/ticket/598#comment:1 https://svn.boost.org/trac10/ticket/598#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">assigned</span> → <span class="trac-field-new">closed</span> </li> </ul> <pre class="wiki">Logged In: YES user_id=52572 Accepted, but changed to factor more code into the Boost.Python compiled library rather than inlining it in each extension module. I do think these are "true leaks," actually. Py_Finalize support would not have touched this memory. Thanks for the patch. It's in the CVS HEAD (too late for 1.34.0). </pre> Ticket