public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/52389] New: Allocation/deallocation across DLL boundary in std::locale
@ 2012-02-26 11:18 athrac++@gmail.com
  2012-02-26 13:32 ` [Bug libstdc++/52389] " redi at gcc dot gnu.org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: athrac++@gmail.com @ 2012-02-26 11:18 UTC (permalink / raw)
  To: gcc-bugs

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.


^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-04-19 10:40 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-26 11:18 [Bug libstdc++/52389] New: Allocation/deallocation across DLL boundary in std::locale athrac++@gmail.com
2012-02-26 13:32 ` [Bug libstdc++/52389] " redi at gcc dot gnu.org
2012-02-26 16:49 ` paolo.carlini at oracle dot com
2014-12-21 10:33 ` redi at gcc dot gnu.org
2014-12-21 11:02 ` redi at gcc dot gnu.org
2015-04-22 12:01 ` jakub at gcc dot gnu.org
2015-07-16  9:14 ` rguenth at gcc dot gnu.org
2021-04-19 10:40 ` redi at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).