Re: [boost] [date_time] [MSVC8] Memory leak in operator<<(ptime)

From: Alo Sarv (alo.sarv_at_[hidden])
Date: 2006-02-17 12:46:10

On 2/17/06, Jeff Garland <jeff_at_[hidden]> wrote:
> Well, that's odd.  The only place that date-time does an allocation is in
> operator<< and operator>>.  So there 'could' be a problem with leaking in that
> code -- either a bug in date-time code or standard library code.  However,
> time_duration and posix_time use the exact same allocation techniques (and
> facet code) so should exhibit the exact same leaking behavior.  Basically,
> what gets allocated is a custom date-time facet that gets imbued into the
> stream.  This gets done on the first call to operator>> or operator<< on a
> particular stream.  After that it just uses the facet avoiding the allocation.
>  The facet is written to work with C++ I/O streams which has a reference
> counting and should destroy the facet when the stream is destroyed.  In the
> case of std::cout this may be after main has exited.

Yes, the first place I looked was that code as well, and thought
perhaps the custom facet doesn't get destroyed properly. However, that
facet is only created once, so that doesn't seem to be the cause,
especially considering other operator<<'s also use basically the same
code.

> If you want to trace it thru you could explicitly create and delete a
> stringstream and check it's behavior.  The date-time code that does the
> allocations is in date_time/posix_time/posix_time_io.hpp.

These two snippets also exhibit the leakage (around 50-80kb/s):

using namespace boost::posix_time;
ptime p(second_clock::local_time());

while (true) {
  std::ostringstream *o = new std::ostringstream;
  *o << p;
  delete o;
}

while (true) {
  std::ostringstream() << p;
}

So clearly it's not some kind of hidden std::cout buffering by the
library that could've caused this. I also stepped through the entire
call hiearchy of the operator<< in debugger but couldn't find anything
of use / suspicious.

I attempted to use Purify to trace the leakage further, but apparently
(at least my version) can't understand the debug format of MSVC8, and
I don't have older version of the compiler around right now. But it
did display some 4000 bytes leaked, just didn't say from where.

--
Alo Sarv