[Bug libstdc++/54296] New: using the object in the map to erase element from the map crashes

[plasmahh at gmx dot net]

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

             Bug #: 54296
           Summary: using the object in the map to erase element from the
                    map crashes
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassig...@gcc.gnu.org
        ReportedBy: plasm...@gmx.net


I found a crash in my program, which boils down to the following code. (Note
that this does usually not crash, but will be reported by valgrind with invalid
read after free. Also note that depending no possible internals of the bucket
hashing stuff, the value for i where it crashes might change, so you can use
the random part multiple times to figure out a new one)

#include <unordered_map>
#include <cstddef>
#include <cstdlib>
#include <cassert>
#include <ctime>
#include <iostream>

struct A
{
        int x;
};

int main ( )
{
        srand(time(0));
        std::unordered_map<int,A> map;
        map.max_load_factor(2.0);

        for (size_t i = 0; i < 50; ++i)
        {
                A a;
                a.x = i;
                map.insert({i,a});
        }

//      int i = rand() % map.size();
        int i = 47;
        std::cout << "i = " << i << "\n";

        const A& a = map[i];

        map.erase(a.x);
}
// vim: tabstop=4 shiftwidth=4 noexpandtab ft=cpp






This seems to be due to the while condition in hashtable.h:1526 accessing __k
after the _M_deallocate_node(__p) of line 1517

while (__next_bkt == __bkt && this->_M_equals(__k, __code, __next_n));

I think it is better that after the erase of the node, __k should not be
touched anymore as it migh be part of the object being erased.