https://svn.boost.org/trac10/ticket/2645 <p> After exhausting all available shared memory by inserting objects into a multimap until a bad_alloc exception is thrown, then deleting all the objects that were successfully inserted, calling size() will still return 1 even though the container is really empty. Also, memory is leaked if the exception is thrown during the insert as subsequent rounds of insert/delete cycles are able to insert less items than the iteration than came before it. </p> <p> Some info about my test scenario... The object that I'm inserting contains an interprocess vector and dynamically allocates an interprocess_mutex using the vector's shared memory allocator storing it's pointer in the object itself. Also, the size of the vector is dynamic, but is bounded to a maximum size so that the maximum size of an object can be predicted. </p> <p> I was able to work around this by performing a successful alloc/dealloc of a size equal to or larger than the size of the inserted object before doing the insert. If the alloc fails then I do not perform the insert. If I do this then the size() remains consistent and no memory is leaked. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/2645 Trac 1.4.3 Ion Gaztañaga Thu, 26 Aug 2010 10:57:32 GMT https://svn.boost.org/trac10/ticket/2645#comment:1 https://svn.boost.org/trac10/ticket/2645#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">wontfix</span> </li> </ul> <p> I couldn't reproduce the problem. Reopen the issue please, if you can find a testcase that fails. </p> Ticket