SIGFPE when accessing unordered_map

In my case the same problem occurred because of static init fiasco. From one object file I called emplace() for static std::unordered_map which was defined in the second object file. Because of at start data was at BSS, value of bucket count was zero => SIGFPE.

Aside: if your hash function cannot throw then it's quite important to give it a noexcept exception-specification, otherwise the hash table needs to store every element's hash code alongside the element itself (which increases memory usage and affects performance) so that container operations that must not throw do not have to recalculate the hash code.

The SIGFPE implies a divide by zero and from the backtrace it happens here:

    { return __num % __den; }

which probably means __den is zero. That value comes from the hash map's bucket count, which should not be zero.

Can you confirm that when it crashes m._M_bucket_count is zero?

If so, that either indicates you've corrupted the map somehow (have you tried compiling with -D_GLIBCXX_DEBUG to turn on the libstdc++ Debug Mode checks? Have you tried running under valgrind?) or there's a bug in the libstdc++ code (which is possible, but unlikely).

Some of the other answers below give examples of how the map can be corrupted, e.g. allocating storage for it with malloc but not actually constructing an object in that storage, or overwriting the object with memset.

Another possibility is that your hash map is a global variable, and you are accessing it from the constructor of another global variable, which runs into the Static Initialization Order Fiasco. If the map is used before its constructor runs, then the bucket count will be zero.