SIGFPE when accessing unordered_map

问题

I have an unordered_map<Block, int> with Block being a simple struct defined as follows:

struct Block {
    size_t start;
    size_t end;

    bool operator==(const Block& b) const {
        return start == b.start && end == b.end;
    }
};

namespace std {
template<>
struct hash<Block> {
    size_t operator()(const Block& b) const {
        return b.start;
    }
};
}

When trying to access the map, I do get the following error message in gdb (same for both g++ 4.7.1 as well as clang++ 3.1):

Program received signal SIGFPE, Arithmetic exception.
0x0000000000401e0b in std::__detail::_Mod_range_hashing::operator() (this=0x7fffffffd8e0, __num=0, __den=0)
    at /usr/include/c++/4.7/bits/hashtable_policy.h:245
245     { return __num % __den; }

My libstdc++ version is 3.4.17 (i.e. the version from GCC 4.7)

Relevant backtrace:

#0  0x0000000000401e0b in std::__detail::_Mod_range_hashing::operator() (this=0x7fffffffd8e0, __num=0, __den=0)
    at /usr/include/c++/4.7/bits/hashtable_policy.h:245
#1  0x0000000000407199 in std::__detail::_Hash_code_base<Block, std::pair<Block const, int>, std::_Select1st<std::pair<Block const, int> >, std::hash<Block>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, true>::_M_bucket_index (this=0x7fffffffd8e0, __c=0, __n=0) at /usr/include/c++/4.7/bits/hashtable_policy.h:787
#2  0x0000000000405230 in std::_Hashtable<Block, std::pair<Block const, int>, std::allocator<std::pair<Block const, int> >, std::_Select1st<std::pair<Block const, int> >, std::equal_to<Block>, std::hash<Block>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, true, false, true>::_M_bucket_index
    (this=0x7fffffffd8e0, __k=..., __c=0) at /usr/include/c++/4.7/bits/hashtable.h:466
#3  0x00000000004038de in std::__detail::_Map_base<Block, std::pair<Block const, int>, std::_Select1st<std::pair<Block const, int> >, true, std::_Hashtable<Block, std::pair<Block const, int>, std::allocator<std::pair<Block const, int> >, std::_Select1st<std::pair<Block const, int> >, std::equal_to<Block>, std::hash<Block>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, true, false, true> >::at (
    this=0x7fffffffd8e0, __k=...) at /usr/include/c++/4.7/bits/hashtable_policy.h:474
#4  0x0000000000403001 in SplicedAlignment::FindOptimalEndBlock() const::{lambda(Block const&)#1}::operator()(Block const&) const (__closure=0x7fffffffd990, block=...) at splicing.cpp:151
#5  0x00000000004040b3 in std::for_each<__gnu_cxx::__normal_iterator<Block const*, std::vector<Block, std::allocator<Block> > >, SplicedAlignment::FindOptimalEndBlock() const::{lambda(Block const&)#1}>(__gnu_cxx::__normal_iterator<Block const*, std::vector<Block, std::allocator<Block> > >, SplicedAlignment::FindOptimalEndBlock() const::{lambda(Block const&)#1}, SplicedAlignment::FindOptimalEndBlock() const::{lambda(Block const&)#1}) (__first=..., __last=..., __f=...)
    at /usr/include/c++/4.7/bits/stl_algo.h:4442

Edit: I didn't think it would actually make a difference where I call the function as long as I give it the same arguments, but apparently it does:

std::for_each(blocks.begin(), blocks.end(), [&](const Block& block) {
    map.at(block);
}

leads to the error, while just having:

const Block& block = blocks[0];
map.at(block);

works perfectly fine (blocks being a simple vector<Block>&)

回答1:

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.

回答2:

I had exactly the same problem. It was caused by memset accidentally applied to container data.

回答3:

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

回答4:

Following the tradition of other users reporting their own circumstances that caused FPE in STL code, here goes mine:

We had perfectly fine code that started dying with SIGFPE in std::map since we upgraded the compiler. Turns out, I compiled gcc 9.2 with gcc 4.8.5 in c++11 mode which is not a normal thing to do -- the normal gcc compilation is always performed in gnu++98 mode.

This caused the 4.8.5 gcc, which has an incomplete/unofficial support for c++11, to produce a faulty 9.2 gcc, which sporadically produced binaries that would exhibit various unrelated failures. For example, trying to debug the above SIGFPE led to SIGSEGV in std::basic_string destructor when compiled with -D_GLIBCXX_DEBUG, and unrelated memory corruption detected with -fsanitize=address.

Lesson here is two-fold:

Do not modify the gcc build system unless you know very darn well what you're doing.
Sometimes the fault can be in the compiler (but then again, the fault ends up being with whomever compiled the compiler...).

来源：https://stackoverflow.com/questions/13580823/sigfpe-when-accessing-unordered-map

标签

c++

gcc

clang

libstdc++