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

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

[athrac++@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: unassigned@gcc.gnu.org
        ReportedBy: athrac++@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.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dave.korn.cygwin at gmail
                   |                            |dot com

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-26 12:35:07 UTC ---
I seem to remember some special tricks being done to handle replacement
functions on Windows and thought it should work - Dave, could you comment?

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

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-02-26 16:28:17 UTC ---
To be clear, x86_64 linux is fine both mainline and 4_6-branch (first blush, I
thought the issue was related to 50594, which is fixed only in mainline)

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-12-21
     Ever confirmed|0                           |1

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I suppose we could add a function to delete the name so it's done in the
library with the matching deallocation function.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.0                         |5.2

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 5.1 has been released.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.2                         |5.3

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 5.2 is being released, adjusting target milestone to 5.3.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|redi at gcc dot gnu.org            |unassigned at gcc dot gnu.org