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).