How unordered_map cause sigsegv [closed]

Question

EDIT: solved, I know how but I don't understand why.

I changed variables declaration from

tr1::unordered_map<int,T> variables;

to

unordered_map<int,T> variables;

and it's work fine.

If you know why please write it in the answers.

I have a very large program, so I don't know which code I should bring here.

There is abstract class, that inherits with derived class. The abstract have unordered_map<int,int> (template) as private member, and public method insert(int,int).

The derived class use the base class insert method to insert elements to the unordered_map<int,int> container,

The first int uses like counter and start with 0. The first eleven insert elements going O.K. but in the 12th element I get sigsegv,and fault in struct equal_to at stl_function.h(209).

In the debugger I have saw that the unordered_map's bucket_count equal to 11, maybe it's clue for something.

My compiler is gcc 4.6.1.

Maybe you can write in general what can cause sigsegv in unordered_map.insert?

Thank you, and sorry about my poor English.

I will bring specific code, if I know which.

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;
    }
};

The declaration is:

tr1::unordered_map<int,T> variables;

The sigsegv happend when arrayPlace==11, And it dosn't matter what value equal.

Answer 1

The answer to the question is very simple: if you use the code correctly, no segmentation fault will be created by std::unordered_map! So the question becomes: what are typical user errors when using std::unordered_map? Off-hand I would think immediately of three issues:

1. The objects are placed into the map as values. That is, the objects need be copyable or movable. That is, I would investigate whether the type T you got correctly implements copy construction. In particular, you want to pay attention to the copy constructor if it isn't in the class but the class has an assignment operator or a destructor.
2. The hash key computed isn't really a hash key but something possibly depending on the location of the object. This would cause funny behavior because the object move to some extend (although once they are inserted they stay put).
3. Similar to the previous issue, the equality operation isn't really an equality operation. The unordered map needs the equality operator to determine if two objects with the same hash code are indeed the same.

Given that the key is an int and the hash code and equality are provided I would concentrate on the first issue. That is, I would concentrate on this once I have proved that the use of the std::unordered_map is indeed the problem: the segmentation violation may also quite easily result from things being messed up earlier. For example, something may have overwritten memory or deleted memory the wrong way, etc. Tools like purify or valgrind can help finding these issue. In any case, you want to boil down the program to a minimal crashing example. Typically I find that the issue becomes obvious in the process.