I've looked into this further using both the C runtime library's
debugging facilities and BoundsChecker with the following results...

Roland wrote:
>  As I understand this, it has to do with MFC's handling of Leakage
>  reporting.

Only partially. MFC checks for leaks too early, so some of the memory
it reports as leaked is actually released later. There are still some
legitimate leaks, however; for instance, MFC leaks some memory having
to do with its own thread local storage handling.

>  However I am still not sure what really is going on, but I think my
>  false "leakage" isn't caused by boost.thread. I was able to track
>  down the offending allocation to the locale handling of the iostream
>  library, which happens to be used in "once".

This is the cause of the memory leaks not leaked by MFC.

In addition, though Boost.Thread isn't leaking memory per se, it does
appear to have a leak of sorts: as far as I can see, the call to
TlsAlloc() in the init_cleanup_key() function in tss.cpp is never
balanced by a call to TlsFree().

>  So I think all that can be done in the moment is to remember this,
in
>  case anyone else discovers the "leakage".

Or change the call_once() function not to use the iostream library.
Since what it's doing with the stream library might be done more
efficiently another way, perhaps it's worth considering.

>  BTW.: After having applied your suggested setting of the DbgFlag
>  my example does not report leakage any more. (Do I have a more
>  recent SP?)

I was using VS6SP5; what about you?

>  Roland
> 
> 
>  _______________________________________________
>  Unsubscribe & other changes:
>  http://lists.boost.org/mailman/listinfo.cgi/boost



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost