libtcmalloc_debug complains about new/free mismatch in stl code
GoogleCodeExporter opened this issue · comments
What steps will reproduce the problem?
1. compile and run attached program with LD_PRELOAD=libtcmalloc_debug.so
What is the expected output? What do you see instead?
Expected no output, got:
memory allocation/deallocation mismatch at 0x9829160: allocated with new
being deallocated with free
Aborted
What version of the product are you using? On what operating system?
tcmalloc 1.4,
linux, gcc-4.0.2 and gcc-4.3.3
Please provide any additional information below.
It looks as if the gcc-stl's delete is called with converts the delete into
a free.
------ gcc-4.0.2/libstdc++-v3/libsupc++/del_opnt.cc -------
_GLIBCXX_WEAK_DEFINITION void
operator delete (void *ptr, const std::nothrow_t&) throw ()
{
if (ptr)
free (ptr);
}
----------------------------
#0 0x0082b7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x07bd57a5 in raise () from /lib/tls/libc.so.6
#2 0x07bd7209 in abort () from /lib/tls/libc.so.6
#3 0x05678e08 in RAW_LOG (lvl=-4,
pat=0x5698e58 "memory allocation/deallocation mismatch at %p: allocated
with %s being deallocated with %s") at ./src/base/logging.h:189
#4 0x0567a8e6 in MallocBlock::CheckLocked (this=0x96fa850, type=0)
at src/debugallocation.cc:481
#5 0x05697d17 in free (ptr=0x96fa860) at src/debugallocation.cc:408
#6 0x07b80fb1 in operator delete (ptr=0x0)
at ../../../../gcc-4.0.2/libstdc++-v3/libsupc++/del_opnt.cc:40
#7 0x011e115b in std::return_temporary_buffer<std::pair<int, QString> > (
__p=0x96fa860)
at
/gcc-4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/memory:
123
#8 0x011eea17 in ~_Temporary_buffer (this=0xbff965f4)
at
/gcc-4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/bits/st
l_tempbuf.h:129
#9 0x012e9b29 in
std::stable_sort<__gnu_cxx::__normal_iterator<std::pair<int, QString>*,
std::vector<std::pair<int, QString>, std::allocator<std::pair<int, QString>
> > >,
auxiliary_n::gui_n::comboboxBaseImpl_c<stationTypes_c>::alphabetical_sorting>
(__first={_M_current = 0x9a28010}, __last=
{_M_current = 0x9a28068}, __comp={<No data fields>})
at
/gcc-4.0.2/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2/bits/st
l_algo.h:3677
Original issue reported on code.google.com by weidenri...@gmx.de
on 24 Sep 2009 at 10:36
Attachments:
Hmm, weird. tcmalloc should be intercepting new(size, nothrow_t). So frame 6
(in
del_opnt.c) should never be called -- that should be part of tcmalloc.
I'm curious why it's not. I'm able to reproduce the problem, even when linking
in
tcmalloc_debug at link time (rather than using LD_PRELOAD), so I'll see what I
can
track down.
Original comment by csilv...@gmail.com
on 24 Sep 2009 at 8:11
- Changed state: Accepted
- Added labels: Priority-Medium, Type-Defect
OK, i figured out the issue: the call in <memory> is
return_temporary_buffer(_Tp* __p)
{ ::operator delete(__p, nothrow); }
I've never heard of a nothrow version of delete before. In theory it doesn't
exist.
Some looking on the web indicates it's for internal use. I will have to track this
down more (there's indication operator delete(size, nothrow_t) exists, but not
operator delete[](size, nothrow_t). In any case, I'll look to fix this up for
the
net release.
Original comment by csilv...@gmail.com
on 24 Sep 2009 at 8:25
I verified overriding delete(void*, nothrow_t) in debugallocation fixed the
problem.
I'll have that in the next release.
Original comment by csilv...@gmail.com
on 24 Sep 2009 at 9:03
- Changed state: Started
This should be fixed in perftools 1.5, just released.
Original comment by csilv...@gmail.com
on 20 Jan 2010 at 11:11
- Changed state: Fixed