Hello, On Tue, May 15, 2012 at 9:07 PM, Christian Henning 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 #include

#define BOOST_FILESYSTEM_VERSION 3 #include

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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users