Google Perftools not detecting all leaks

[GoogleCodeExporter]

What steps will reproduce the problem?
1. create simple program (attached test.c)
2. compile it with make (attached Makefile)
3. run with tcmalloc preloaded (attached test.sh)

What is the expected output?
280 bytes lost

What do you see instead?
240 bytes lost

What version of the product are you using? On what operating system?
- gperftools-2.1
- Linux <snip> 2.6.32-358.18.1.el6.x86_64 <snip> x86_64 x86_64 x86_64 GNU/Linux

Please provide any additional information below.
- tried also with linked tcmalloc (-ltcmalloc to gcc) - same output
- when you uncomment printf in test.c file, there will be expected 280 bytes 
lost

Original issue reported on code.google.com by patrik...@gmail.com on 26 Nov 2013 at 10:04

Attachments:

• Makefile
• test.c
• test.sh

[GoogleCodeExporter]

Forgot to mention that valgrind detects the last leak, so it's probably not 
problem with compilation.

Original comment by patrik...@gmail.com on 26 Nov 2013 at 11:08

[GoogleCodeExporter]

I think it's the same issue with issue 
537(https://code.google.com/p/gperftools/issues/detail?id=537)

To avoid this, I use 
(1)export HEAPCHECK="draconian"
(2)run program
(3)pprof ./test.bin "/tmp/test.bin.57880._main_-end.heap" 
--ignore='_dl_rtld_di_serinfo' --lines --show_bytes --pdf > 1.pdf

As draconian will report gperftools objects as leak too.

Original comment by xiaoyur...@gmail.com on 1 Jan 2014 at 11:52

[GoogleCodeExporter]

Interesting, on my FreeBSD system the original testcase shows "detected leaks 
of 120 bytes in 3 objects"

But when I place "printf("something\n")" after each malloc, output changes: 
"detected leaks of 280 bytes in 7 objects"

Something isn't quite right.

Original comment by yuriv...@gmail.com on 28 Aug 2014 at 9:40

[GoogleCodeExporter]

Additionally, result also depends on compiler. My previous result was with 
clang.
With gcc even with printf it reports "detected leaks of 160 bytes in 4 objects
" (vs. correct result with clang)

Original comment by yuriv...@gmail.com on 28 Aug 2014 at 9:52