libtcmalloc_debug complains about new/free mismatch in stl code

[GoogleCodeExporter]

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:

• tcmalloc_debug_test.cpp

[GoogleCodeExporter]

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
• Removed labels: ****

[GoogleCodeExporter]

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

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

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
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

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
• Added labels: ****
• Removed labels: ****