koolhazz / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

double free protection #638

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. allocate sizeof(int) bytes using malloc: get a pointer
2. free the pointer
3. free the same pointer again ("double free")
4. all sequent calls to malloc for sizeof(int), return the same pointer 

What is the expected output? What do you see instead?
I'd expect that TCMALLOC will detect double-free scenario and either signal an 
error or ignore a free-call for an-already-freed pointer.
instead, the pointer is entered twice into the free-list and same address is 
returned more than once afterwards on malloc calls.

What version of the product are you ? On what operating system?
2.2 , centos-5.3

Please provide any additional information below.

Original issue reported on code.google.com by ais.rd.i...@gmail.com on 30 Jul 2014 at 9:41

GoogleCodeExporter commented 9 years ago
This is by design. Have you tried -ltcmalloc_debug ?

Original comment by alkondratenko on 30 Jul 2014 at 10:23

GoogleCodeExporter commented 9 years ago
Thanks.
What is the difference between tcmalloc_minimal_debug and tcmalloc_minimal ? 
is it only the additional error-checks?
Is there any benchmark results on the expected performance penalty when  
tcmalloc_debug ?

Original comment by ais.rd.i...@gmail.com on 3 Aug 2014 at 8:54

GoogleCodeExporter commented 9 years ago
I was unable to find any documentation on debug malloc. It does check for 
things like double free, off by <some> bytes writes etc. Only source of 
information on this that I'm aware of is debugallocation.cc.

Original comment by alkondratenko on 3 Aug 2014 at 7:43

GoogleCodeExporter commented 9 years ago
Closing as wont fix due to "by design"-ness of lack of double free checking.

Original comment by alkondratenko on 3 Aug 2014 at 7:43