[Bug libstdc++/25956] New: Memory error when dynamic linking STL specializations

[Bug libstdc++/25956] New: Memory error when dynamic linking STL specializations

[jkp at kirkconsulting dot co dot uk]

Summay:

I've found what appears to be a bug when using new basic_string specializations
in dynamically linked code under 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"

Steps to Reproduce: 

Theu bug can be reproduced by creating a dynamic library (either a framework or
a dylib) with the following code in and then linking to and calling that code
from your main binary:

#include <iostream>
#include <locale>
#include <ext/pod_char_traits.h>

typedef __gnu_cxx::character<uint16_t, int>     CharType;
typedef std::char_traits<CharType>                  TraitType;
typedef std::basic_string<CharType>                UTFString;

class TestClass
{
public:
        UTFString Test();
};

UTFString TestClass::Test( )
{
    CharType s1[] = { '\0' };
    return s1;
}

 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.

Expected Results: 

No error message from free.

Actual Results: 

The above warning is emitted in the console.

Regression: 

I have tested the same code on Linux under x86_64 and also 10.4.4 on an Intel
Mac.  Neither of those platforms exhibit the same behaviour.  

Notes:

I have filed this bug with Apple, and also mailed the developer list for
libstdc++ to see if anyone knows anything.


-- 
           Summary: Memory error when dynamic linking STL specializations
           Product: gcc
           Version: 4.0.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jkp at kirkconsulting dot co dot uk
 GCC build triplet: 10.4.4
  GCC host triplet: Mac OS X


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

[Bug libstdc++/25956] Memory error when dynamic linking STL specializations

[jkp at kirkconsulting dot co dot uk]

------- Comment #1 from jkp at kirkconsulting dot co dot uk  2006-01-25 08:52 -------
Created an attachment (id=10726)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10726&action=view)
XCode project with test case

The project includes three targets - the main application, a dylib and a static
lib.  If you play with the membership of the targets in the main app you can
see how staticlly linking the code will make the issue go away.


-- 


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

[Bug libstdc++/25956] Memory error when dynamic linking STL specializations

[pcarlini at suse dot de]

------- Comment #2 from pcarlini at suse dot de  2007-03-26 22:08 -------
The message to the libstdc++ list:

  http://gcc.gnu.org/ml/libstdc++/2006-01/msg00155.html


-- 


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

[Bug libstdc++/25956] Memory error when dynamic linking STL specializations

[bkoz at gcc dot gnu dot org]

------- Comment #3 from bkoz at gcc dot gnu dot org  2009-01-27 04:23 -------

This seems like a template linkage bug specific to the powerpc-darwin8.5.0
target, probably related to simulated/incomplete support of comdat and weak
linkage on that platform via coalesced symbols. It seems unlikely to be fixed,
although I suppose miracles happen every day.

I do not believe this is specific to libstdc++, IMHO. That it does not happen
on other architectures of darwin (ie x86) or on non-darwin hosts make me leery
of adding this workaround to the docs. 

What is the link to the Apple bug report?

I see this on x86/linux for your code sample:

%eu-readelf -s 2weak.o | grep Rep
  109: 0000000000000000     32 OBJECT  WEAK   DEFAULT      120
_ZNSbIN9__gnu_cxx9characterIti11__mbstate_tEESt11char_traitsIS2_ESaIS2_EE4_Rep20_S_empty_rep_storageE

both with and without -fno-weak. 

This seems to be another instance of gcc/28017: I would like to close this as a
duplicate of that bug report, if the bug reporter is agreeable. 


-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |28017
           Keywords|                            |documentation


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

[Bug libstdc++/25956] Memory error when dynamic linking STL specializations

[jkp at kirkconsulting dot co dot uk]

------- Comment #4 from jkp at kirkconsulting dot co dot uk  2009-01-27 13:44 -------
Hi there

I reported this bug too long ago to even remember the details.  All I can say
is that now PPC OS X is probably completely irrelevant to most people.  I
certainly won't be wasting any more time on it.  That said: perhaps if this
issue is a PPC thing it still warrants investigation.

Thanks

Jamie


-- 


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

[Bug libstdc++/25956] Memory error when dynamic linking STL specializations

[bkoz at gcc dot gnu dot org]

------- Comment #5 from bkoz at gcc dot gnu dot org  2009-01-27 17:26 -------

Duplicate

*** This bug has been marked as a duplicate of 28017 ***


-- 

bkoz at gcc dot gnu dot org changed:

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


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