[filesystem] Memory leaks when building with MSVC 2010
Hi there, I'm stumbling over some memory leaks reported by MSVC when using boost::filesystem. Here is simple code sample that can reproduce the output below: #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 -> {268} normal block at 0x0000000000457450, 32 bytes long. Data: <C : \ b l a . d > 43 00 3A 00 5C 00 62 00 6C 00 61 00 2E 00 64 00 {145} normal block at 0x0000000000457F50, 24 bytes long. Data: < .? > A8 09 2E 3F 01 00 00 00 01 00 00 00 00 00 00 00 {143} normal block at 0x0000000000457E50, 16 bytes long. Data: <8 > 38 F9 16 00 00 00 00 00 00 00 00 00 00 00 00 00 {142} normal block at 0x0000000000457DD0, 16 bytes long. Data: <@ .? > 40 8B 2E 3F 01 00 00 00 00 00 00 00 00 00 00 00 {141} normal block at 0x0000000000457D50, 16 bytes long. Data: < .? > 10 8B 2E 3F 01 00 00 00 00 00 00 00 00 00 00 00 Object dump complete. The program '[1860] test.exe: Native' has exited with code 0 (0x0). Is this a known issue/nonissue? I have a test suite that uses boost::filesystem in numerous areas and the output is somewhat disturbing to me. Regards, Christian
Hello, On Tue, May 15, 2012 at 8:26 PM, Christian Henning <chhenning@gmail.com>wrote:
Hi there,
I'm stumbling over some memory leaks reported by MSVC when using boost::filesystem. Here is simple code sample that can reproduce the output below:
#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" );
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? Cheers, Will
_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 -> {268} normal block at 0x0000000000457450, 32 bytes long. Data: <C : \ b l a . d > 43 00 3A 00 5C 00 62 00 6C 00 61 00 2E 00 64 00 {145} normal block at 0x0000000000457F50, 24 bytes long. Data: < .? > A8 09 2E 3F 01 00 00 00 01 00 00 00 00 00 00 00 {143} normal block at 0x0000000000457E50, 16 bytes long. Data: <8 > 38 F9 16 00 00 00 00 00 00 00 00 00 00 00 00 00 {142} normal block at 0x0000000000457DD0, 16 bytes long. Data: <@ .? > 40 8B 2E 3F 01 00 00 00 00 00 00 00 00 00 00 00 {141} normal block at 0x0000000000457D50, 16 bytes long. Data: < .? > 10 8B 2E 3F 01 00 00 00 00 00 00 00 00 00 00 00 Object dump complete. The program '[1860] test.exe: Native' has exited with code 0 (0x0).
Is this a known issue/nonissue? I have a test suite that uses boost::filesystem in numerous areas and the output is somewhat disturbing to me.
Regards, Christian _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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? ;-) Christian
Hello, On Tue, May 15, 2012 at 9:07 PM, Christian Henning <chhenning@gmail.com>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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi Will,
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.
You are correct. It was my fault. It's a non-issue. Thanks again for you advice, Christian
participants (2)
-
Christian Henning -
Will Mason