std::vector memory leak issues

Mathew Jared Bergen · 2013-11-12T17:26:55

Hello, I have an entity with a std::vector<Component*> m_components (Component is an abstract base class all other Components inherit from so I can polymorph them) and when I destroy the entity I clear the vector like so: Entity::~Entity(){ for(std::vector<Component*>::iterator iter = m_components.begin(); iter != m_components.end(); ++iter){ delete *iter; *iter = NULL; } m_components.clear(); m_components.shrink_to_fit(); } and I get memory leaks. I looked online and everywhere I look it looks like I am doing it right. The memory leaks are a jumble of numbers: Detected memory leaks! Dumping objects -> {377} normal block at 0x05804D28, 8 bytes long. Data: < N > 90 4E 80 05 00 00 00 00 {376} normal block at 0x05804E80, 80 bytes long. Data: < c w c > 90 B1 63 05 D8 81 77 05 90 B1 63 05 00 00 CD CD {374} normal block at 0x05884028, 98304 bytes long. Data: < > 00 00 FF FF 00 00 FF FF 00 00 FF FF 00 00 FF FF {373} normal block at 0x05804E38, 8 bytes long. Data: < M > A4 4D 80 05 00 00 00 00 {372} normal block at 0x05804DF0, 8 bytes long. Data: < M > 80 4D 80 05 00 00 00 00 {371} normal block at 0x05804D70, 68 bytes long. Data: < c w c > C8 B0 63 05 C8 80 77 05 C8 B0 63 05 00 00 CD CD {353} normal block at 0x05778268, 8 bytes long. Data: < w > E8 81 77 05 00 00 00 00 {352} normal block at 0x057781D8, 80 bytes long. Data: < c *x N > 90 B1 63 05 10 2A 78 05 80 4E 80 05 01 00 CD CD {350} normal block at 0x057839A0, 262144 bytes long. Data: < $ $ $ $ > 83 24 0C FF 83 24 0C FF 83 24 0C FF 83 24 0C FF {349} normal block at 0x05778190, 8 bytes long. Data: < w > FC 80 77 05 00 00 00 00 {348} normal block at 0x05778148, 8 bytes long. Data: < w > D8 80 77 05 00 00 00 00 {347} normal block at 0x057780C8, 68 bytes long. Data: < c x pM > C8 B0 63 05 08 19 78 05 70 4D 80 05 01 00 CD CD {326} normal block at 0x05772908, 8 bytes long. Data: < *x > 20 2A 78 05 00 00 00 00 {325} normal block at 0x05782A10, 80 bytes long. Data: < &w c w > 18 26 77 05 90 B1 63 05 D8 81 77 05 01 00 CD CD {323} normal block at 0x057819D0, 4096 bytes long. Data: < > FF 00 00 FF FF 00 00 FF FF 00 00 FF FF 00 00 FF {322} normal block at 0x05781988, 8 bytes long. Data: << x > 3C 19 78 05 00 00 00 00 {321} normal block at 0x05772950, 8 bytes long. Data: < x > 18 19 78 05 00 00 00 00 {320} normal block at 0x05781908, 68 bytes long. Data: <@"w c w > 40 22 77 05 C8 B0 63 05 C8 80 77 05 01 00 CD CD {303} normal block at 0x0577A100, 8 bytes long. Data: <(&w > 28 26 77 05 00 00 00 00 {302} normal block at 0x05772618, 80 bytes long. Data: < c *x c > 90 B1 63 05 10 2A 78 05 90 B1 63 05 01 00 CD CD {299} normal block at 0x05779030, 4096 bytes long. Data: < > FF 00 00 FF FF 00 00 FF FF 00 00 FF FF 00 00 FF {298} normal block at 0x05772308, 8 bytes long. Data: <t"w > 74 22 77 05 00 00 00 00 {297} normal block at 0x057722C0, 8 bytes long. Data: <P"w > 50 22 77 05 00 00 00 00 {296} normal block at 0x05772240, 68 bytes long. Data: < c x c > C8 B0 63 05 08 19 78 05 C8 B0 63 05 01 00 CD CD {275} normal block at 0x0563B220, 8 bytes long. Data: <| c > 7C B0 63 05 00 00 00 00 {274} normal block at 0x0563B190, 80 bytes long. Data: < &w *x N > 18 26 77 05 10 2A 78 05 80 4E 80 05 01 01 CD CD {273} normal block at 0x0563B148, 8 bytes long. Data: <p c > 70 B0 63 05 00 00 00 00 {272} normal block at 0x0563B0C8, 68 bytes long. Data: <@"w x pM > 40 22 77 05 08 19 78 05 70 4D 80 05 01 01 CD CD {271} normal block at 0x0563B070, 24 bytes long. Data: <H c c c > 48 B1 63 05 C8 B0 63 05 04 00 00 00 20 B2 63 05 {171} normal block at 0x0357F378, 40 bytes long. Data: < 5_ > D4 C5 35 5F 18 00 00 00 08 00 00 00 00 00 00 00 {170} normal block at 0x003FBFE8, 40 bytes long. Data: < 5_ > D4 C5 35 5F 18 00 00 00 08 00 00 00 00 00 00 00 Object dump complete. I am using VS2012's built in system for detecting memory leaks. This is the only place I am dynamically allocating anything in my program and when I comment out everything that has to do with the vector I get no errors. Thanks for any help.

For Beginners

Started by Crusable77 November 12, 2013 08:57 AM

11 comments, last by Crusable77 11 years, 3 months ago

NightCreature83

5,063

November 12, 2013 02:40 PM

In the future use vld2 as it will extend the VS2012 memory leak tracker with proper callstacks, this makes it a lot easier to track where your leaks are coming from.

Your leaks will look more like this:



---------- Block 1199 at 0x04BE1058: 136 bytes ----------
Call Stack:
d:\Foobar\FooLog.cpp (26): FooLog::getInstance
d:\Foobar\FooMain.cpp (75): FooMain::init
f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (578): __tmainCRTStartup
f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (403): WinMainCRTStartup
0x759A3677 (File and line number not available): BaseThreadInitThunk
0x770C9D42 (File and line number not available): RtlInitializeExceptionChain
0x770C9D15 (File and line number not available): RtlInitializeExceptionChain
Data:
9C 33 2D 6B 74 2A 2D 6B C8 11 BE 04 00 00 00 00 .3-kt*-k ........
00 00 00 00 70 14 BB 6C 70 14 BB 6C 00 00 00 00 ....p..l p..l....
00 00 00 00 68 14 BB 6C 68 14 BB 6C 00 00 00 00 ....h..l h..l....
00 00 00 00 6C 14 BB 6C 6C 14 BB 6C 20 12 BE 04 ....l..l l..l....
00 00 00 00 CD 00 CD CD 00 00 00 00 01 CD CD CD ........ ........
68 14 BB 6C 78 33 2D 6B 00 00 00 00 00 00 00 00 h..lx3-k ........
00 00 00 00 01 02 00 00 06 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 88 11 BE 04 5C 10 BE 04 ........ ....\...
00 00 00 00 20 CD CD CD ........ ........

The output lines are double click able to jump to the actual allocation, and instead of the define all you need to do is include vld.h somewhere, point to the lib and include dir and all is done, in release vld will not compile with your project so no need for markers around the header.

Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, theHunter, theHunter: Primal, Mad Max, Watch Dogs: Legion

alvaro

21,610

November 12, 2013 02:46 PM

Here's something else you can do: Reduce your program to the simplest possible program that still shows a leak. Just make a copy of your code and start taking out anything that doesn't have to do with the problem at hand. You'll get to a point where anything you remove will stop showing the problem. We'll call that a "minimal program".

In the process of finding that minimal program, you'll very often figure out the problem yourself. And if you don't, you can always post the program here (it shouldn't be more than 40 lines) and you'll get much better help.

This is a general procedure that works for many types of bugs.