Ich habe unordered_map<Block, int> , wobei Block eine einfache Struktur ist, die wie folgt definiert ist:
Beim Versuch, auf die Map zuzugreifen, erhalte ich die folgende Fehlermeldung in gdb (das gilt sowohl für g ++ 4.7.1 als auch für clang ++ 3.1):
%Vor%Meine libstdc ++ Version ist 3.4.17 (d. h. die Version von GCC 4.7)
Relevantes Backtrace:
%Vor%Edit: Ich dachte nicht, dass es tatsächlich einen Unterschied machen würde wo Ich rufe die Funktion auf, solange ich dieselben Argumente gebe, aber anscheinend tut es das:
%Vor%führt zu dem Fehler, obwohl nur:
%Vor% funktioniert einwandfrei ( blocks ist eine einfache vector<Block>& )
Nebenbei: Wenn Ihre Hash-Funktion nicht werfen kann, ist es sehr wichtig, ihr eine noexcept -Ausschlussspezifikation zu geben, andernfalls muss die Hash-Tabelle den Hash-Code jedes Elements neben dem Element selbst speichern (was die Speicherauslastung erhöht) wirkt sich auf die Leistung aus, sodass Containeroperationen, die nicht ausgelöst werden müssen, den Hashcode nicht neu berechnen müssen.
Der SIGFPE impliziert eine Division durch Null und vom Backtrace kommt es hier vor:
%Vor% was wahrscheinlich bedeutet, dass __den gleich Null ist. Dieser Wert stammt aus der Bucket-Anzahl der Hash-Map, die nicht Null sein sollte.
Können Sie bestätigen, dass bei einem Absturz m._M_bucket_count gleich null ist?
Wenn ja, deutet das entweder darauf hin, dass du die Karte irgendwie korrumpiert hast (hast du versucht mit -D_GLIBCXX_DEBUG zu kompilieren, um die libstdc ++ Debug-Modus-Prüfungen zu aktivieren? Hast du versucht, unter valgrind zu laufen?) oder es gibt einen Fehler in der libstdc ++ code.
Ich hatte genau das gleiche Problem. Es wurde verursacht, indem Memset versehentlich auf Containerdaten angewendet wurde.
In meinem Fall trat das selbe Problem wegen statischem init fiasco auf. Von einer Objektdatei habe ich emplace-Methode für statische std :: unordered_map aufgerufen, die in der zweiten Objektdatei definiert wurde. Da zu Beginn Daten bei BSS waren, war der Wert der Bucket-Zählung Null = & gt; SIGFPE.