Поврежденные одноэлементные данные с использованием CxxTest

двойное освобождение и дамп ядра

Я думаю, что могу объяснить проблему «двойного бесплатного и основного дампа», с которой вы столкнулись. Недавно я столкнулся с тем же самым, и похоже, что вы делаете то же самое, что и я.

Из вашего описания вы сказали, что когда вы «запускаете их по отдельности», они работают нормально, но если вы «запускаете их вместе», вы получаете двойную проблему с дампом ядра.

Я обнаружил, что это происходит, если один и тот же глобальный объект объявляется дважды.

В моем случае у меня был класс foo, в одном файле у меня был глобальный class foo gFoo;, а в другом файле у меня был глобальный class foo gFoo;. (Да, это звучит глупо, на самом деле я связывался с файлом X.cxx, а также с общей библиотекой, которая также включала X.cxx — результаты были практически одинаковыми.)

Теперь я ожидал, что компилятор пожалуется на это, но, видимо, есть флаги для включения или отключения этой проверки, и код скомпилирован нормально. Но когда программа завершала работу и вызывала все свои деструкторы, она дважды вызывала деструкторы gFoo и выдавала мне двойное бесплатное сообщение вместе с дампом ядра.

Учитывая, что вы заявили, что он отлично работает независимо, но терпит неудачу при объединении, я держу пари, что у вас есть глобальный, определенный в двух отдельных файлах, и он отлично работает, когда они скомпилированы сами по себе, но когда вы объединяете их, чтобы сделать один тест, вы вероятно, глобальная декларация происходит дважды.

Проверь это.

статические переменные в C и C++ не являются потокобезопасными. Это означает, что условия гонки (плохая вещь) могут возникнуть, если два потока попытаются получить доступ к вашему одноэлементному объекту. Один из подходов к решению вашей проблемы — использовать локальное хранилище потоков. Это поддерживается библиотекой pthreads, а также некоторые компиляторы напрямую поддерживают локальное хранилище потоков.

Альтернативой, если ваш синглтон ДОЛЖЕН быть глобальным для всех потоков, является предоставление блокировки, чтобы гарантировать, что только один поток может получить доступ к вашим данным за раз.

Однако проблема возникает только при модульном тестировании. Я бы посоветовал не запускать многопоточные модульные тесты, если вы не собираетесь использовать свой синглтон в нескольких потоках.

Это сильно зависит от используемого вами компилятора и платформы, и, не видя тестов, я могу только догадываться о том, что происходит.

Я вижу некоторые неправильные представления в вашем коде:
1) Вам не хватает оператора копирования и конструктора копирования. Вы копируете экземпляры, содержащие std::string, которые могут быть реализованы с использованием подсчета ссылок. Подсчет ссылок реализован в перегруженном конструкторе/операторе копирования std::string, но они могут не вызываться из неявно сгенерированного конструктора копирования вашего класса и, следовательно, вызывать двойное освобождение памяти и другие неприятные вещи. Оператор/конструктор копирования должен выглядеть так:

// Copy constructor
Parms(const Parms& oth)  { parm1 = oth.parm1; parm2 = oth.parm2; }

// Copy operator
Parms& operator= (const Parms& oth)  { 
  if (&oth == this)  // Check for self-assignment
    return *this;
  parm1 = oth.parm1;
  parm2 = oth.parm2;
  return *this;
}

2) Я не совсем понимаю наличие value1 и value2. Кажется, вы никогда их не инициализируете, вы просто используете их в конструкторе по умолчанию, чтобы скопировать их (пустое) содержимое в parm1 и parm2. Вы можете полностью избежать этого, так как parm1 и parm2 автоматически инициализируются пустой строкой при вызове.

3) Здесь не нужно использовать шаблон singleton. Метод getDefaults() может быть реализован следующим образом:

static Parms getParms() { return Parms(); }

Шаблон singleton предназначен для классов, у которых есть только один экземпляр во время выполнения всей программы, что, похоже, не относится к вашему классу.

Таким образом, вы можете безопасно использовать функцию getParms() из нескольких потоков, и умный компилятор оптимизирует подразумеваемую дополнительную копию.