This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/54296] New: using the object in the map to erase element from the map crashes
- From: "plasmahh at gmx dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 17 Aug 2012 13:07:46 +0000
- Subject: [Bug libstdc++/54296] New: using the object in the map to erase element from the map crashes
- Auto-submitted: auto-generated
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: unassigned@gcc.gnu.org
ReportedBy: plasmahh@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.