How unordered_map calls sigsegv

Question

EDITOR: decided, I know how, but I don’t understand why.

I changed the declaration of variables from

 tr1::unordered_map<int,T> variables; 

to

 unordered_map<int,T> variables; 

and it works great.

If you know why, please write in the answers.

I have a very large program, so I don’t know what code I need to bring here.

There is an abstract class that inherits a derived class. In the abstract there is unordered_map<int,int> (template) as a private member and the public insert(int,int) method.

The resulting class uses the insert base class method to insert elements into the container unordered_map<int,int> ,

The first int used as a counter and starts at 0. The first eleven plug-in elements go OK, but in the 12th element I get sigsegv and an error in struct equal_to in stl_function.h (209).

In the debugger, I saw that unordered_map bucket_count is 11, maybe it tells something.

My compiler is gcc 4.6.1.

Maybe you can even write what sigsegv can call in unordered_map.insert ?

Thank you and regret my poor English.

I will bring specific code if I know which one.

EDIT: This is the insert method:

 virtual void Insert(int arrayPlace, T value) { if (!isReadOnly) { if (IsValueDataValid(value)) { variables[arrayPlace] = value; } else { throw 2; } } else { throw 4; } }; 

Ad:

 tr1::unordered_map<int,T> variables; 

sigsegv happend when arrayPlace == 11, and it doesn't matter what value is.

Answer 1

The answer to the question is very simple: if you use the code correctly, then std::unordered_map will not generate a segmentation error! So the question is: what are the typical user errors when using std::unordered_map ? Out of my hands, I would immediately think of three problems:

• Objects are placed on the map as values. That is, objects must be copyable or movable. That is, I would investigate whether type T implements copy construction correctly. In particular, you want to pay attention to the copy constructor if it is not in the class, but the class has an assignment operator or destructor.
• The calculated hash key is not really a hash key, but perhaps depending on the location of the object. This can cause fun behavior because the object moves in some part (although after they are inserted, they remain in place).
• As in the previous release, the equality operation is not really an equality operation. An unordered map needs an equality operator to determine if two objects with the same hash code are really the same.

Given that the key is int , and hash code and equality are provided, I would like to focus on the first issue. That is, I would focus on this as soon as I proved that using std::unordered_map really a problem: breaking segmentation can also be easily the result of things being messed up before. For example, something may be overwritten by memory or remote memory incorrectly, etc. Tools such as cleaning or valgrind can help find this problem. In any case, you want to minimize the program to a minimal failure example. Usually I find that the problem becomes apparent in this process.