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]

Incorrect delete called from map< > destructor.


Hi guys,

Found a nasty little bug in the 19981101 snapshot.  This one was a real
head-scratcher to get isolated.

In my code, I provided a placement-new operator and a corresponding
placement-delete for when my constructors throw.

Well, for some reason, if I dynamically allocate a map (instantiated with
any ol' types it seems) and then use plain-old delete when I'm done with it,
the placement-delete operator is called from the guts of the map destructor!

The same test case works fine under 1.1b.

Here's my test program.  Relevant compiler information is: egcs-2.92.18
sparc-sun-solaris2.5.1
Configured with --enable-threads --enable-shared

#include <iostream.h>
#include <new>
#include <map>

struct SomeClass { };

void* operator new(size_t numBytes, SomeClass&, const nothrow_t&) throw()
{
    cout << "Nobody calls this.  What happened?" << endl;
    return operator new(numBytes, nothrow);
}

void operator delete(void* pMemory, SomeClass&, const nothrow_t&) throw()
{
    cout << "Never in a million years should we be in here..." << endl;
    return operator delete(pMemory);
}

int
main()
{
    map< int, int>* pMap = new map< int, int>;

    // Within the map destructor, it calls the wrong delete somehow...

    delete pMap;

    //
    // Using an automatic map instead of allocating one dynamically works
fine.
    //

    map< int, int> aMap;

    return 0;
}

Compiling this with or without debugging and with or without optimizations
always produces the same result: the placement-delete operator is called.

Ouch...

Thanks guys,

Jeff



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