Boost logo

Boost :

From: Roland (roland.schwarz_at_[hidden])
Date: 2004-01-21 02:51:44


(Michael Glassford <glassfordm_at_[hidden]>) wrote:

>
> First of all, if I understand correctly, in your example you put the
> _CrtDumpMemoryLeaks() call too early: since it simply lists all blocks
> that are allocated at the time when it is called, it should normally
> be called at a point where all memory ought to have been freed; so the
> beginning of the main() function seems to be the wrong place for it. A
> better way would be the end of main() (though this is still too early
> in that static objects haven't been destroyed and released their
> memory yet); perhaps even better is to call
>
> CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF |
> _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG))
>
> which sets a flag telling the memory allocator to check for leaks on
> exit. However, even with these methods I still see "leaks" reported. I
> have yet to determine which of them are real problems and which are
> valid behavior, but will look into it.

Thanks, I think I have figured this out also in the meantime. To tell the whole story:
I discovered the "leakage" while compiling a MFC program. There you
don't need to do this explicitely.

But I found the following discussion on
microsoft.public.vc.language: Memory leaks in DLL

http://groups.google.at/groups?q=Memory+leaks+in+DLL&hl=de&lr=&ie=UTF-8&oe=UTF-8&selm=ebjezuKp%24GA.315%40cppssbbsa04&rnum=2

As I understand this, it has to do with MFC's handling of Leakage reporting.
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".

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

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?)

Roland


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk