c++ segfault on one platform (MacOSX) but not another (linux) - c++

Question

I'm getting a segfault on MacOSX ("Segmentation fault: 11", in gdb "Program received signal SIGSEGV, Segmentation fault"), appearing in the destructor in which a container is looped over with an iterator and memory deleted. I've tried with clang++, g++ (both part of LLVM) and homebrew g++. The segfault appears when the iterator is incremented for the first time, with the gdb message (having compiled with clang++)
"0x000000010001196d in std::__1::__tree_node_base<void*>* std::__1::__tree_next<std::__1::__tree_node_base<void*>*>(std::__1::__tree_node_base<void*>*) ()"
When starting the program in gdb I also get warnings saying "warning: Could not open OSO archive file".
On a cluster linux node, with gcc 4.8.1, I don't get a segfault. Any ideas what might be wrong and how I can avoid the segfault on my mac (preferably with clang)? I really don't know much about compilers and such.
EDIT:
I think I found the problem, however I'd like to understand still why this works on one platform but not another. Here's a minimal example:
class Word:
#ifndef WORD_H
#define WORD_H
#include <string>
#include <map>
class Word {
public:
/*** Constructor ***/
Word(std::string w) : m_word(w) {
// Add word to index map, if it's not already in there
std::map<std::string, Word*>::iterator it = index.find(w);
if (it == index.end()) {
index[w] = this;
}
}
~Word() { index.erase(m_word); } // Remove from index
static void DeleteAll() { // Clear index, delete all allocated memory
for (std::map<std::string, Word*>::const_iterator it = index.begin();
it != index.end();
++it)
{ delete it->second; }
}
private:
std::string m_word;
static std::map<std::string, Word*> index; // Index holding all words initialized
};
#endif
WordHandler class:
#ifndef _WORDHANDLER_H_
#define _WORDHANDLER_H_
#include <string>
#include "Word.h"
class WordHandler {
WordHandler() {}
~WordHandler() { Word::DeleteAll(); } // clear memory
void WordHandler::NewWord(const std::string word) {
Word* w = new Word(word);
}
};
#endif
Main program:
#include <iostream>
#include "WordHandler.h"
int main () {
std::cout << "Welcome to the WordHandler. " << std::endl;
WordHandler wh;
wh.NewWord("hallon");
wh.NewWord("karl");
std::cout << "About to exit WordHandler after having added two new words " << std::endl;
return 0;
}
So the segfault occurs upon exiting of the program, when the destructor ~WordHandler is called. The reason I found, is the Word destructor: the Word object is erased from the map, which makes the DeleteAll() function weird because the map is altered while it's being iterated over (some sort of double delete I suppose). The segfault disappears either by removing the DeleteAll completely, or removing the Word destructor.
So I'm still wondering why the segfault doesn't appear on linux with g++ from gcc 4.8.1. (Also, I guess off topic, I'm wondering about the programming itself – what would be the proper way to treat index erasing/memory deletion in this code?)
EDIT 2:
I don't think this is a duplicate of Vector.erase(Iterator) causes bad memory access, because my original question had to do with why I get a segfault on one platform and not another. It's possible that the other question explains the segfault per se (not sure how get around this problem... perhaps removing the Word destructor and calling erase from DeleteAll() rather than "delete"? But that destructor makes sense to me though...), but if it's truly a bug in the code why isn't picked up by gcc g++?

Answer 1

This is a problem:
~Word() { index.erase(m_word); } // Remove from index
static void DeleteAll() { // Clear index, delete all allocated memory
for (std::map<std::string, Word*>::const_iterator it = index.begin();
it != index.end();
++it)
{ delete it->second; }
}
delete it->second invokes ~Word which erases from the map that you are iterating over. This invalidates your active iterator, leading to undefined behaviour. Because it is UB, the fact that it works on one platform but not another is basically just luck (or lack thereof).
To fix this, you can either make a copy of index and iterate over that, consider a different design that doesn't mutate the index as you delete it, or use the fact that erase returns the next valid iterator to make the loop safe (which means hoisting the erase into DeleteAll).