public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/34164]  New: Inconsistent size used for allocate/deallocate for std::string
@ 2007-11-20 15:15 Aaron dot m dot camac at boeing dot com
  2007-11-20 17:50 ` [Bug libstdc++/34164] " pcarlini at suse dot de
  2007-11-20 17:53 ` pcarlini at suse dot de
  0 siblings, 2 replies; 3+ messages in thread
From: Aaron dot m dot camac at boeing dot com @ 2007-11-20 15:15 UTC (permalink / raw)
  To: gcc-bugs

Looking at 4.1.1 
/data_storage/obj-4.1.1/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc

It looks as though the size is incorrectly figured for the deallocate.   
_M_destroy uses sizeof(_Rep_base) where _S_create uses sizeof(_Rep) to
determine the size of the allocation. Based on the header it looks like _Rep is
larger.

I can't say I've had an errror with this, but I was just dumpster diving the
code to figure out a purify error and came across this inconsitency. It doesn't
really do anything when you use the default allocator, since deallocate doesn't
use the size in the default.

  template<typename _CharT, typename _Traits, typename _Alloc>
    void
    basic_string<_CharT, _Traits, _Alloc>::_Rep::
    _M_destroy(const _Alloc& __a) throw ()
    {
      const size_type __size = sizeof(_Rep_base) +
                               (this->_M_capacity + 1) * sizeof(_CharT);
      _Raw_bytes_alloc(__a).deallocate(reinterpret_cast<char*>(this), __size);
    }

  template<typename _CharT, typename _Traits, typename _Alloc>
    typename basic_string<_CharT, _Traits, _Alloc>::_Rep*
    basic_string<_CharT, _Traits, _Alloc>::_Rep::
    _S_create(size_type __capacity, size_type __old_capacity,
              const _Alloc& __alloc)
    {
      // _GLIBCXX_RESOLVE_LIB_DEFECTS
      // 83.  String::npos vs. string::max_size()
      if (__capacity > _S_max_size)
        __throw_length_error(__N("basic_string::_S_create"));
      const size_type __pagesize = 4096;
      const size_type __malloc_header_size = 4 * sizeof(void*);

      if (__capacity > __old_capacity && __capacity < 2 * __old_capacity)
        __capacity = 2 * __old_capacity;

      size_type __size = (__capacity + 1) * sizeof(_CharT) + sizeof(_Rep);

      const size_type __adj_size = __size + __malloc_header_size;
      if (__adj_size > __pagesize && __capacity > __old_capacity)
        {
          const size_type __extra = __pagesize - __adj_size % __pagesize;
          __capacity += __extra / sizeof(_CharT);
          // Never allocate a string bigger than _S_max_size.
          if (__capacity > _S_max_size)
            __capacity = _S_max_size;
          __size = (__capacity + 1) * sizeof(_CharT) + sizeof(_Rep);
        }

      // NB: Might throw, but no worries about a leak, mate: _Rep()
      // does not throw.
      void* __place = _Raw_bytes_alloc(__alloc).allocate(__size);
      _Rep *__p = new (__place) _Rep;
      __p->_M_capacity = __capacity;
      return __p;
    }


-- 
           Summary: Inconsistent size used for allocate/deallocate for
                    std::string
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: Aaron dot m dot camac at boeing dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34164


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug libstdc++/34164] Inconsistent size used for allocate/deallocate for std::string
  2007-11-20 15:15 [Bug c++/34164] New: Inconsistent size used for allocate/deallocate for std::string Aaron dot m dot camac at boeing dot com
@ 2007-11-20 17:50 ` pcarlini at suse dot de
  2007-11-20 17:53 ` pcarlini at suse dot de
  1 sibling, 0 replies; 3+ messages in thread
From: pcarlini at suse dot de @ 2007-11-20 17:50 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from pcarlini at suse dot de  2007-11-20 17:49 -------
No, no, don't worry about that, the syntactic difference is an old workaround
for a front-end limitation, doesn't matter, _Rep doesn't have any non-static
member and the size is the same. By the way, we already received from time to
time reports about spurious messages from purify, I would suggest
double-checking with valgrind, which, to my best knowledge, is happy with our
implementation (not just in the basic_string area) also because includes
specific "suppressions" (see the docs about that).


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34164


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug libstdc++/34164] Inconsistent size used for allocate/deallocate for std::string
  2007-11-20 15:15 [Bug c++/34164] New: Inconsistent size used for allocate/deallocate for std::string Aaron dot m dot camac at boeing dot com
  2007-11-20 17:50 ` [Bug libstdc++/34164] " pcarlini at suse dot de
@ 2007-11-20 17:53 ` pcarlini at suse dot de
  1 sibling, 0 replies; 3+ messages in thread
From: pcarlini at suse dot de @ 2007-11-20 17:53 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from pcarlini at suse dot de  2007-11-20 17:53 -------
... also, I can tell you that at least a couple of times I saw either valgrind
or purify stumbling on basic_string where the actual (real) memory leak was in
user code, elsewhere, the memory was just unpredictably tainted...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34164


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-11-20 17:53 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-11-20 15:15 [Bug c++/34164] New: Inconsistent size used for allocate/deallocate for std::string Aaron dot m dot camac at boeing dot com
2007-11-20 17:50 ` [Bug libstdc++/34164] " pcarlini at suse dot de
2007-11-20 17:53 ` pcarlini at suse dot de

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).