Dynamic linking specializations

[Jamie Kirkpatrick <jkp at kirkconsulting dot co dot uk>]

Hey guys.

I've found what appears to be a bug when using new basic_string  
specializations in dynamically linked code under OS X.  I've been  
battling for literally two days to track this one down, and I've  
managed to produce a test case that is as simple as possible - as I  
say, it does seem to be something that only manifests itself on OS X.

The 'bug' exhibits itself when you create a new string of your custom  
type with zero length.  As you all probably know, basic_string has a  
static struct (accessed via _S_empty_rep() ) that it assigns as the  
data value when this is the case.  The problem is that when the  
destructor is called the class is trying to free the placeholder  
struct (something that should never happen).  It causes the program  
to output an error which is as follows:

"malloc: ***  Deallocation of a pointer not malloced: 0x18078; This  
could be a double free(), or free() called with the middle of an  
allocated block; Try setting environment variable MallocHelp to see  
tools to help debug"

I have spent a long time looking into this, and in the end I was able  
to eliminate my code as being at fault since i have reproduced the  
same error using the provided templates in <ext/pod_char_traits.h>.   
The problem shows itself only when the function that creates the  
string is compiled into some dynamically linked code (either a  
framework or a dylib on os x).

I have created a simple sample project which is an Xcode project.  It  
has three targets, a static lib, a dynamic lib and the main app  
(which is just main with a call to my test function).  If someone on  
the dev team has access to an OS X box they can play around switching  
the library that is linked into the executable - if you chose the  
dylib it will error, whilst a static lib will be fine (same code).  I  
have dug in with the debugger to see what I could find out, and as  
far as I can tell there are different instances of _S_empty_rep  
hanging around when it is dynamically linked, though Im not entirely  
certain.  Whatever it is, something is causing the destructor to  
think that it is not looking at _S_empty_rep but at a real string.

I have compiled the code under linux to see if the same problem  
occured there but I had no luck reproducing it (I compiled the test  
function into a shared library to try for the same effect), and I  
have also had a friend with an Intel Mac try it out - he also had not  
luck.  So, it appears to be localized to just OS X under PPC - I'm  
running the latest public release, which is 10.4.4.  Are there any  
known implications of dynamically linking such code?

I have uploaded the project to my webspace so people can get at it  
easily - the URL is www.kirkconsulting.co.uk/StringMemoryError.zip

I hope that someone will have time to look into this as I've banged  
my head against a brick wall for two days now!  I'd appreciate any  
information that could be provided.  I'm not too sure what the real  
impact of the problem is, but it means that I cannot Malloc Debug my  
app because it will just hit this error and die.

I hope that I have provided sufficient information for this to be  
investigated, any further queries please shout me...

Many thanks

Jamie Kirkpatrick