This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]