Re: C++ std::string tries to free() a not allocated pointer ?
Re: C++ std::string tries to free() a not allocated pointer ?
- Subject: Re: C++ std::string tries to free() a not allocated pointer ?
- From: Howard Moon <email@hidden>
- Date: Thu, 19 Nov 2009 10:45:30 -0800
On Nov 19, 2009, at 10:01 AM, Howard Hinnant wrote:
On Nov 19, 2009, at 11:37 AM, Jean-Denis Muys wrote:
I finally managed to step through all this. It's not pretty.
I stepped through this assembly for the routine that allocates the
std::string, the first in the stack backtrace:
#0 0x99056cb4 in std::string::_S_construct<char const*> ()
#1 0x99056d85 in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string ()
#2 0x041fc8c7 in sql::SQLString::SQLString (this=0xb02e6a4c,
s=0x4beccb0 "", n=0) at sqlstring.h:43
Its signature is:
template
C*
S::_S_construct(const C*, const C*, const allocator<C>&,
forward_iterator_tag);
the first two parameters are the pointers to the first and the last
characters of the source string. This is crucial, because that
routine tests for these two pointers to be equal, which happens
when the source string is "".
in that case, it will return a special value for the std::string
internal buffer, always the same one, which is not allocated, but
which is at a fixed offset from the code itself. That sounds like a
static const to me.
My commented relevant assembly is at the end of this post.
So of course this pointer is not allocated, and of course malloc
complains when the destructor tries to free it.
So is this a bug in the standard library? As I wrote, a toy program
trying to reproduce this fails to exhibit the issue.
So my theory is the following: the library and my code were linked
with different, incompatible versions of the standard C++ library
1- The library, which calls the constructor, uses a version of the
library that optimizes the special case of empty strings with a
static const char[].
2- My code, which calls the destructor, uses a version of the
library that doesn't expect that optimization.
Next questions:
1- How can I confirm that theory, given that I compiled both, the
library from the terminal using the generated make file, and my
code from XCode.
2- How can I find/control/check/change which version of the
standard C++ library is linked with either my code or the library?
Though I found the cause of the problem, I feel no closer to a
solution.
Your thorough analysis has solved the problem!! :-)
libstdc++ (the standard c++ library) has a flag called:
_GLIBCXX_FULLY_DYNAMIC_STRING
The libstdc++ is compiled with this flag *not* defined. This causes
a statically allocated default string to be constructed with a
reference count that never can go to 0 (and thus get deallocated).
It appears that somehow you are compiling with
_GLIBCXX_FULLY_DYNAMIC_STRING defined, and I believe that is the
cause of your crash.
According to a post on svn.macport.org, Snow Leopard is built with
that flag *defined*!
<https://svn.macports.org/ticket/22234>
That post references a discussion on gcc.gnu.org:
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645>
I'm not sure how to interpret all of that discussion, but it does seem
to be a library problem under Snow Leopard.
-Howard (no relation)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden