ddio / gperftools

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

1.4 debug crashes on double free #190

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Compile the following program and link against any tcmalloc_debug variant
int main(int, char **)
{
   int * pint = new int;
   delete pint;
   delete pint;
   return 0;
}
2. Run it
dmin@dev-rc1:~$ g++ -g df.cpp -o df -ltcmalloc_debug
admin@dev-rc1:~$ ./df
Segmentation fault
admin@dev-rc1:~$ gdb ./df
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) r
Starting program: /home/admin/df 

Program received signal SIGSEGV, Segmentation fault.
0xb7f0c7d6 in ?? () from /usr/lib/libtcmalloc_debug.so.0
(gdb) bt
#0  0xb7f0c7d6 in ?? () from /usr/lib/libtcmalloc_debug.so.0
#1  0xb7f2c8c7 in operator delete () from /usr/lib/libtcmalloc_debug.so.0
#2  0x0804858a in main () at df.cpp:5
(gdb) 

What is the expected output? What do you see instead?
I expected some error message when linked against the _debug variants. 
However, it just crashes on the second delete

What version of the product are you using? On what operating system?
libgoogle-perftools0_1.4-1_i386.deb downloaded from download page
32 bit Ubuntu 8.04.3

Please provide any additional information below.

Original issue reported on code.google.com by nkie...@gmail.com on 16 Nov 2009 at 5:07

GoogleCodeExporter commented 9 years ago
You're absolutely right!  Our code to print a double-free warning got some 
bitrot at
some point, and stopped working.  We'll fix that up for the next release.

Original comment by csilv...@gmail.com on 16 Nov 2009 at 7:24

GoogleCodeExporter commented 9 years ago
Does this impact the free() function of tcmalloc_debug, that is double free()?

Original comment by JassenM@gmail.com on 17 Nov 2009 at 4:37

GoogleCodeExporter commented 9 years ago
Yes, free() and delete are the same internally.  In both cases, a double-free 
will
crash, rather than print an error message and *then* crash.  So the 
functionality
isn't broken, just the reporting.

Original comment by csilv...@gmail.com on 17 Nov 2009 at 4:47

GoogleCodeExporter commented 9 years ago
Can you please point me to the location of the tcmalloc code and the change that
needs to be made so I can patch this myself?

Original comment by JassenM@gmail.com on 17 Nov 2009 at 4:48

GoogleCodeExporter commented 9 years ago
What kind of change are you looking for?  Do you want to make it so that the 
code
doesn't crash on double-free?  Or do you just really need it to be printing the 
error
message before it crashes?  You sound pretty bothered by what is, in reality, a
pretty minor bug, so I want to make sure I understand what change you're 
looking for.

The file in question is src/debugallocation.cc.  The fix isn't entirely 
trivial, but
as soon as it's reviewed I'll be checking it in to the svn repository.

Original comment by csilv...@gmail.com on 17 Nov 2009 at 6:29

GoogleCodeExporter commented 9 years ago
This should be fixed in perftools 1.5, just released.

Original comment by csilv...@gmail.com on 20 Jan 2010 at 11:08