[Bug libstdc++/52389] New: Allocation/deallocation across DLL boundary in std::locale

[athra...@gmail.com]

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

             Bug #: 52389
           Summary: Allocation/deallocation across DLL boundary in
                    std::locale
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: libstdc++
        AssignedTo: unassig...@gcc.gnu.org
        ReportedBy: athra...@gmail.com


#include <locale>
#include <cstdlib>
#include <cstdio>
#include <new>

void* operator new[](size_t size)
{
    char* p = (char*)malloc(size + 16);
    if(!p) throw std::bad_alloc();
    *(uint32_t*)p = 0x12345678;
    return p + 16;
}

void operator delete[](void* p)
{
    char* p2 = (char*)p - 16;
    if(*(uint32_t*)p2 != 0x12345678)
        printf("block was not allocated with new[]\n");
    free(p2);
}

struct F : std::locale::facet
{
    F() : facet(0) {}
    static std::locale::id id;
};
std::locale::id F::id;

int main()
{
    std::locale path_locale(std::locale(), new F);
    return 0;
}

Building with MinGW 4.6.2 using command: g++ test.cpp -o test.exe
Produces output: "block was not allocated with new[]"

So the problem occurs when libstdc++ is linked dynamically and there are custom
operator new[]/delete[], and you construct a std::locale object as above. It
seems the constructor allocates some memory using new[] in the DLL, and then
frees the block with the custom delete[] in the executable.

I did some digging in to the source code, and the delete[] call was from
locale_classes.tcc line 56, and the corresponding allocation was done in
locale.cc line 281.

Now I don't know if libstdc++ even tries to support custom allocation functions
with dynamic linking, but at least this one should be fixable.