|
From: Matthias S. <zz...@ge...> - 2013-10-09 04:53:36
|
On 02.10.2013 23:03, Philippe Waroquiers wrote: > Have you tested these heuristics with a (big) c++ application ? Philippe Hi Philippe, I did some real tests with our application. This is from one "smaller" test run: ==3917== LEAK SUMMARY: ==3917== definitely lost: 7,145,200 (+0) bytes in 2,117 (+0) blocks ==3917== indirectly lost: 39,872 (+0) bytes in 1,246 (+0) blocks ==3917== possibly lost: 1,140,720 (-558,683) bytes in 201 (-3,297) blocks ==3917== still reachable: 6,742,624 (+558,683) bytes in 44,916 (+3,297) blocks ==3917== of which reachable via heuristic: ==3917== stdstring : 5,527 (+5,527) bytes in 157 (+157) blocks ==3917== newarray : 308,552 (+308,552) bytes in 2,525 (+2,525) blocks ==3917== multipleinheritance: 7,928 (+7,928) bytes in 4 (+4) blocks ==3917== Array64Length : 244,584 (+244,584) bytes in 614 (+614) blocks ==3917== suppressed: 0 (+0) bytes in 0 (+0) blocks ==3917== To see details of leaked memory, give 'full' arg to leak_check ==3917== You see, we have possible leaks for all of your heuristics: multipleinheritance: 1 matching block, this is correct stdstring: lots of std::string, everything correct here newarray: No data allocated by new[] here, only memory from icu_50::UnicodeString::cloneArrayIfNeeded The problem with icu_50::UnicodeStringis, that is has the reference count in the word before the location pointed at. And that is 1 at the allocation time and later in most cases only a small integer. As long as it is 1, 2 or 4 it should always match the allocated size. In other cases it might match. Then I have the heuristic "array64length" I have written. This one checks if the pointer has offset 8 and the 64bits before match the remaining length (a subset of newarray on a 64bit platform). This one only matches memory allocated by sqlite3 (e.g. sqlite3MemMalloc). The remaining possible leaks can be grouped like this: - icu_50::UnicodeString (when reference count does not match length) - Some internal Pool implementations that maybe should be instrumented - sqlite3MemMalloc (why is this not matching Array64length ??)- pthreads TLS: 38x (one per thread) ==2503== 144 bytes in 1 blocks are possibly lost in loss record 18,895 of 20,196 ==2503== at 0x4006256: calloc (vg_replace_malloc.c:618) ==2503== by 0x4D8477B8: allocate_dtv (dl-tls.c:297) ==2503== by 0x4D847F5E: _dl_allocate_tls (dl-tls.c:461) ==2503== by 0x4DA1A6A0: pthread_create@@GLIBC_2.1 (allocatestack.c:572) […] So multipleinheritance and std::string have no false positives for me. Newarray is not as reliable, as each memory block that starts with a word of 1,2 or 4 will match (if the pointer has offset 4). Maybe some kind of matching is needed for combinations of pointer offset and allocating callstack. Regards Matthias |