Re: [Boost-users] [filesystem] Memory leaks when building with MSVC 2010

Subject: Re: [Boost-users] [filesystem] Memory leaks when building with MSVC 2010
From: Will Mason (willchido_at_[hidden])
Date: 2012-05-15 22:24:57

Hello,

On Tue, May 15, 2012 at 9:07 PM, Christian Henning <chhenning_at_[hidden]>wrote:

> Hi Will, thanks for your quick answer.
>
> > This object, my_path, has not yet gone out of scope. Why would you expect
> > its memory to have been reclaimed in the line that follows?
>
> True. Here is the updated code:
>
> #define _CRTDBG_MAP_ALLOC
>
> #include <stdlib.h>
> #include <crtdbg.h>
>
> #define BOOST_FILESYSTEM_VERSION 3
> #include <boost/filesystem/convenience.hpp>
>
> namespace fs = boost::filesystem;
>
> int main(int argc, char* argv[])
> {
>    {
>         fs::path my_path( "C:/bla.dat" );
>    }
>
>    _CrtDumpMemoryLeaks();
>
>        return 0;
> }
>
> -- output:
>
>
> 'test.exe': Loaded
> 'C:\gil_contributions\solutions\vc10\test\x64\Debug\test.exe', Symbols
> loaded.
> 'test.exe': Loaded 'C:\Windows\System32\ntdll.dll', Cannot find or
> open the PDB file
> 'test.exe': Loaded 'C:\Windows\System32\kernel32.dll', Cannot find or
> open the PDB file
> 'test.exe': Loaded 'C:\Windows\System32\KernelBase.dll', Cannot find
> or open the PDB file
> 'test.exe': Loaded 'C:\Windows\System32\msvcr100d.dll', Symbols loaded.
> 'test.exe': Loaded 'C:\Windows\System32\msvcp100d.dll', Symbols loaded.
> Detected memory leaks!
> Dumping objects ->
> {145} normal block at 0x00000000003F7EE0, 24 bytes long.
>  Data: <   ?            > 88 09 F6 3F 01 00 00 00 01 00 00 00 00 00 00 00
> {142} normal block at 0x00000000003F7D60, 16 bytes long.
>  Data: <@  ?            > 40 8B F6 3F 01 00 00 00 00 00 00 00 00 00 00 00
> {141} normal block at 0x00000000003F7CE0, 16 bytes long.
>  Data: <   ?            > 10 8B F6 3F 01 00 00 00 00 00 00 00 00 00 00 00
> Object dump complete.
> The program '[3628] test.exe: Native' has exited with code 0 (0x0).
>
> It's getting late here. Maybe I don't see the forest because there are
> tree? ;-)
>

I don't know about forests and trees, but I do know that your test could
easily be hiding instances of one-time allocation, which you don't see
because you are also only allocating one boost::filesystem::path. I would
recommend allocating and deleting 50 or 100 ro 100,000 path objects and
seeing if the "leaks" are actually growing.

>From my own experience, we use boost::filesystem *extensively* in a large
cross-platform project, and we perform rather exhaustive memory and static
checking of our binaries on multiple platforms. We have seen no leaks from
boost::filesystem.

Cheers,
Will

>
> Christian
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>