Solved Tracking memory leaks
-
Qt appears to allocate lots of stuff as it goes along and a lot doesn't seem to be deleted.
I've used Visual Leak Detector in the past to keep track of this, but with Qt in the picture the output of non-released memory at process exit is rather overwhelming.
Is there a recommended approach or tool for memory leak detection when Qt is being used.
ISTR there's a flag that tells Qt to delete child objects when their parent is deleted - I hope that this is the default setting?
Thanks
David -
Arghh _ those messages were from Visual Studio's own crappy leak detector (which I forgot to turn off) - VLD only shows about half a dozen leaks all of which are understandable.
e.g.
---------- Block 192 at 0x00000000FDB1F040: 32 bytes ---------- Leak Hash: 0xD54D4C24, Count: 1, Total 32 bytes Call Stack (TID 77940): mfc140ud.dll!0x00007FF97911A0D0() d:\users\amonra\documents\github\dss\deepskystacker\qmfcapp.cpp (314): DeepSkyStacker.exe!QMfcApp::instance() + 0x35 bytes d:\users\amonra\documents\github\dss\deepskystacker\deepskystacker.cpp (252): DeepSkyStacker.exe!CDeepSkyStackerApp::InitInstance() d:\users\amonra\documents\github\dss\deepskystacker\deepskystacker.cpp (396): DeepSkyStacker.exe!wWinMain() d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (123): DeepSkyStacker.exe!invoke_main() d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (288): DeepSkyStacker.exe!__scrt_common_main_seh() + 0x5 bytes d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (331): DeepSkyStacker.exe!__scrt_common_main() d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_wwinmain.cpp (17): DeepSkyStacker.exe!wWinMainCRTStartup() KERNEL32.DLL!BaseThreadInitThunk() + 0x14 bytes ntdll.dll!RtlUserThreadStart() + 0x21 bytes Data: 50 06 B1 FD F4 7F 00 00 E0 76 B0 FD F4 7F 00 00 P....... .v...... 70 63 B1 FD F4 7F 00 00 00 00 00 00 00 00 00 00 pc...... ........Sorry for misdirection. ...
David -
@Perdrix said in Tracking memory leaks:
I hope that this is the default setting?
Yes, parents delete their childs, when destroyed.
-
@Perdrix
Don't know what "Visual Leak Detector" might be. Qt Creator has integration withvalgrind, works good for me under Linux, don't know what OS you are on.QObject-derived objects are always deleted if they have a parent and that is deleted, no flag for that it's automatic. Window flagQt::WA_DeleteOnClosecan optionally be placed on top-level, non-parented windows to ensure delete on closure. WalkingQWidgetList QApplication::allWidgets()can be useful to see what widgets are still in existence. -
Visual Leak Detector is an approximate equivalent to valgrind on Windows.
David
-
The problem is that with Qt in the picture I'm getting 100s of leaked chunks of memory reported when the application is closed.
Prior to using Qt there were three singletons allocated before main startup so were reported as leaks, now I can't see the wood for the trees.
For example:
Detected memory leaks! Dumping objects -> {52775} normal block at 0x00007FF4F7FCDAE0, 136 bytes long. Data: <0 % 0 % > 30 8A 25 F9 F4 7F 00 00 30 8A 25 F9 F4 7F 00 00 {52774} normal block at 0x00007FF4F7FCCF80, 136 bytes long. Data: < > 90 A6 E7 F7 F4 7F 00 00 90 A6 E7 F7 F4 7F 00 00 {52773} normal block at 0x00007FF4F7FCCDE0, 136 bytes long. Data: <p p > 70 A7 E7 F7 F4 7F 00 00 70 A7 E7 F7 F4 7F 00 00 {52772} normal block at 0x00007FF4F7FCDE20, 136 bytes long. Data: < > 00 A7 E7 F7 F4 7F 00 00 00 A7 E7 F7 F4 7F 00 00 {51787} normal block at 0x00007FF4F92DD210, 64 bytes long. Data: <@K r > 40 4B F1 F7 F4 7F 00 00 72 D3 D7 02 CD CD CD CD {51786} normal block at 0x00007FF4F7F1A9C0, 40 bytes long. Data: < [ > E0 84 5B 80 F9 7F 00 00 00 00 CD CD CD CD CD CD {51785} normal block at 0x00007FF4F7EE0F70, 12 bytes long. Data: < > 01 CD CD CD 0A 00 00 00 03 00 00 00 {51784} normal block at 0x00007FF4F7FC0340, 32 bytes long. Data: < W H 7 > F0 57 F1 F7 F4 7F 00 00 48 BA 91 37 CD CD CD CD {51783} normal block at 0x00007FF4F7EFF2C0, 80 bytes long. Data: < P > B8 20 9E 84 F9 7F 00 00 50 00 00 00 15 00 00 00 {51731} normal block at 0x00007FF4F67FC3B0, 6720 bytes long. Data: < v; P A > 00 00 00 00 A3 76 3B A3 DE A1 50 DE FF AD 41 FF {51730} normal block at 0x00007FF4F7FCCEB0, 136 bytes long. Data: < P > 01 00 00 00 50 00 00 00 15 00 00 00 20 00 00 00 {51729} normal block at 0x00007FF4F7F4B120, 178 bytes long. Data: < L M > 01 00 00 00 4C 00 00 00 4D 00 00 00 CD CD CD CD {51681} normal block at 0x00007FF4F92DEF10, 64 bytes long. Data: <@K q > 40 4B F1 F7 F4 7F 00 00 71 D3 D7 02 CD CD CD CD {51680} normal block at 0x00007FF4F7F197D0, 40 bytes long. Data: < [ > E0 84 5B 80 F9 7F 00 00 00 00 CD CD CD CD CD CD {51679} normal block at 0x00007FF4F7EE13D0, 12 bytes long. Data: < > 01 CD CD CD 09 00 00 00 03 00 00 00 {51678} normal block at 0x00007FF4F92DD710, 64 bytes long. Data: < > 01 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 {51677} normal block at 0x00007FF4F7FBF5C0, 32 bytes long. Data: < W G > F0 57 F1 F7 F4 7F 00 00 E8 F2 47 C9 CD CD CD CD {51676} normal block at 0x00007FF4F7EFFB30, 80 bytes long. Data: < P > B8 20 9E 84 F9 7F 00 00 50 00 00 00 15 00 00 00 {51624} normal block at 0x00007FF4F67FA930, 6720 bytes long. Data: < r7 J A > 00 00 00 00 9F 72 37 A3 DA 9C 4A DE FF AD 41 FF {51623} normal block at 0x00007FF4F7FCC4F0, 136 bytes long. Data: < P > 01 00 00 00 50 00 00 00 15 00 00 00 20 00 00 00 {51622} normal block at 0x00007FF4F7F4B7B0, 178 bytes long. Data: < L M > 01 00 00 00 4C 00 00 00 4D 00 00 00 CD CD CD CD {51098} normal block at 0x00007FF4F92DD410, 64 bytes long. Data: <@K p > 40 4B F1 F7 F4 7F 00 00 70 D3 D7 02 CD CD CD CD {51097} normal block at 0x00007FF4F7F19370, 40 bytes long. Data: < [ > E0 84 5B 80 F9 7F 00 00 00 00 CD CD CD CD CD CD {51096} normal block at 0x00007FF4F7EE0C00, 12 bytes long. Data: < > 01 CD CD CD 08 00 00 00 03 00 00 00 {51095} normal block at 0x00007FF4F7FC0940, 32 bytes long. Data: < W > F0 57 F1 F7 F4 7F 00 00 7F AB 80 FF CD CD CD CD {51094} normal block at 0x00007FF4F7EFEDB0, 80 bytes long. Data: < P > B8 20 9E 84 F9 7F 00 00 50 00 00 00 15 00 00 00 {51062} normal block at 0x00007FF4F7F19300, 40 bytes long. Data: < z > F0 7A F1 F7 F4 7F 00 00 02 DA FC 05 CD CD CD CD {51061} normal block at 0x00007FF4F67F78D0, 12320 bytes long. Data: < i > 01 00 00 00 01 00 00 00 69 0E C3 7F F9 7F 00 00 {51057} normal block at 0x00007FF4F7F85D80, 128 bytes long. Data: < > 01 00 00 00 02 00 00 00 04 00 00 00 CD CD CD CD {51040} normal block at 0x00007FF4F67F5E50, 6720 bytes long. Data: < uuu > 00 00 00 00 75 75 75 A3 9F 9F 9F DE AB AB AB FF {51039} normal block at 0x00007FF4F7FCD600, 136 bytes long. Data: < P > 01 00 00 00 50 00 00 00 15 00 00 00 20 00 00 00 {51038} normal block at 0x00007FF4F7F4BF30, 178 bytes long. Data: < L M > 01 00 00 00 4C 00 00 00 4D 00 00 00 CD CD CD CD {50759} normal block at 0x00007FF4F92DE690, 64 bytes long. Data: <@K > 40 4B F1 F7 F4 7F 00 00 7F D3 D7 02 CD CD CD CD {50758} normal block at 0x00007FF4F7F1A090, 40 bytes long. Data: < [ > E0 84 5B 80 F9 7F 00 00 00 00 CD CD CD CD CD CD {50757} normal block at 0x00007FF4F7EE12E0, 12 bytes long. Data: < > 01 CD CD CD 07 00 00 00 03 00 00 00 {50756} normal block at 0x00007FF4F7FBFCE0, 32 bytes long. Data: < W > F0 57 F1 F7 F4 7F 00 00 85 DB AF A1 CD CD CD CD {50755} normal block at 0x00007FF4F7EFEB70, 80 bytes long. Data: < P > B8 20 9E 84 F9 7F 00 00 50 00 00 00 15 00 00 00 {50723} normal block at 0x00007FF4F7F19B50, 40 bytes long. Data: < z ^ > F0 7A F1 F7 F4 7F 00 00 5E CF 9D 0E CD CD CD CD {50722} normal block at 0x00007FF4F67F2DF0, 12320 bytes long. Data: < i > 01 00 00 00 01 00 00 00 69 0E C3 7F F9 7F 00 00 {50718} normal block at 0x00007FF4F7F86140, 128 bytes long. Data: < > 01 00 00 00 02 00 00 00 04 00 00 00 CD CD CD CD {50701} normal block at 0x00007FF4F67F1370, 6720 bytes long. Data: < v; P A > 00 00 00 00 A3 76 3B A3 DE A1 50 DE FF AD 41 FF {50700} normal block at 0x00007FF4F7FCCB70, 136 bytes long. Data: < P > 01 00 00 00 50 00 00 00 15 00 00 00 20 00 00 00 {50699} normal block at 0x00007FF4F7F4B3F0, 178 bytes long. Data: < L M > 01 00 00 00 4C 00 00 00 4D 00 00 00 CD CD CD CD {47675} normal block at 0x00007FF4F7F19220, 48 bytes long. Data: <0 x > 30 87 F1 F7 F4 7F 00 00 78 CB D7 02 18 00 00 00 {47618} normal block at 0x00007FF4F7F19920, 48 bytes long. Data: <0 x 1 > 30 87 F1 F7 F4 7F 00 00 78 E2 D7 02 31 00 00 00 {47563} normal block at 0x00007FF4F7F19CA0, 48 bytes long. Data: <0 x > 30 87 F1 F7 F4 7F 00 00 78 C0 D7 02 13 00 00 00 {47435} normal block at 0x00007FF4F7F1A2C0, 48 bytes long. Data: <0 x > 30 87 F1 F7 F4 7F 00 00 78 C3 D7 02 10 00 00 00 {47265} normal block at 0x00007FF4F7F19D10, 48 bytes long. Data: <0 x > 30 87 F1 F7 F4 7F 00 00 78 DF D7 02 0C 00 00 00 {47263} normal block at 0x00007FF4F7F1A6B0, 48 bytes long. Data: <0 x > 30 87 F1 F7 F4 7F 00 00 78 D8 D7 02 0B 00 00 00 {47259} normal block at 0x00007FF4F7F19DF0, 48 bytes long. Data: <0 x + > 30 87 F1 F7 F4 7F 00 00 78 F8 D7 02 2B 00 00 00 {47223} normal block at 0x00007FF4F7F19840, 48 bytes long. Data: <0 x : > 30 87 F1 F7 F4 7F 00 00 78 E9 D7 02 3A 00 00 00 {44534} normal block at 0x00007FF4F92E1290, 64 bytes long. Data: <@K ~ > 40 4B F1 F7 F4 7F 00 00 7E D3 D7 02 CD CD CD CD {44533} normal block at 0x00007FF4F7F19F40, 40 bytes long. Data: < [ > E0 84 5B 80 F9 7F 00 00 00 00 CD CD CD CD CD CD {44532} normal block at 0x00007FF4F7EE0E80, 12 bytes long. Data: < > 01 CD CD CD 06 00 00 00 03 00 00 00 {44531} normal block at 0x00007FF4F7FBDB20, 32 bytes long. Data: < W qR > F0 57 F1 F7 F4 7F 00 00 A8 B2 71 52 CD CD CD CD {44530} normal block at 0x00007FF4F7EFEF60, 80 bytes long. Data: < P > B8 20 9E 84 F9 7F 00 00 50 00 00 00 15 00 00 00 {44478} normal block at 0x00007FF4F67EF8F0, 6720 bytes long. Data: < uuu > 00 00 00 00 75 75 75 A3 9F 9F 9F DE AB AB AB FF {44477} normal block at 0x00007FF4F7FCD460, 136 bytes long. and hundreds more :(so how to solve this issue.
-
Maybe try Heob to see if it sees the same leaks. Can that memory analyzer give false positives?
-
I've never (ever) seen or heard of false positives reported by Visual Leak Detector, and have used it for yonks.
I'll sneak a peek at Heob (never heard of it before).
David
-
@Perdrix
I'm not sure whether you're saying you know there aren't any leaks in your Qt code, and are therefore confused, or not?Qt appears to allocate lots of stuff as it goes along and a lot doesn't seem to be deleted.
Qt itself does not leak. However, it is (relatively) easy for user Qt code to fail to do what it should do, and thereby leak. Even with the "auto-delete of child objects on parent delete". So could your current list of leaks indeed be down to the Qt code which has been written?
-
Arghh _ those messages were from Visual Studio's own crappy leak detector (which I forgot to turn off) - VLD only shows about half a dozen leaks all of which are understandable.
e.g.
---------- Block 192 at 0x00000000FDB1F040: 32 bytes ---------- Leak Hash: 0xD54D4C24, Count: 1, Total 32 bytes Call Stack (TID 77940): mfc140ud.dll!0x00007FF97911A0D0() d:\users\amonra\documents\github\dss\deepskystacker\qmfcapp.cpp (314): DeepSkyStacker.exe!QMfcApp::instance() + 0x35 bytes d:\users\amonra\documents\github\dss\deepskystacker\deepskystacker.cpp (252): DeepSkyStacker.exe!CDeepSkyStackerApp::InitInstance() d:\users\amonra\documents\github\dss\deepskystacker\deepskystacker.cpp (396): DeepSkyStacker.exe!wWinMain() d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (123): DeepSkyStacker.exe!invoke_main() d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (288): DeepSkyStacker.exe!__scrt_common_main_seh() + 0x5 bytes d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (331): DeepSkyStacker.exe!__scrt_common_main() d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_wwinmain.cpp (17): DeepSkyStacker.exe!wWinMainCRTStartup() KERNEL32.DLL!BaseThreadInitThunk() + 0x14 bytes ntdll.dll!RtlUserThreadStart() + 0x21 bytes Data: 50 06 B1 FD F4 7F 00 00 E0 76 B0 FD F4 7F 00 00 P....... .v...... 70 63 B1 FD F4 7F 00 00 00 00 00 00 00 00 00 00 pc...... ........Sorry for misdirection. ...
David -
Glad you figured it out! Frustrating!
