Segfault на библиотеке плагинов C++ с повторяющимися символами

Question

У меня есть приложение C++ с кросс-платформой, которое разбито на несколько разделяемых библиотек и загружает дополнительные функции из разделяемых библиотек плагинов. Библиотеки плагинов должны быть автономными и работать сами по себе, без знания или зависимости от вызывающего приложения.

Один из плагинов содержит скопированный код из основного приложения, поэтому содержит имена символов, дублирующиеся с именами в движке. (Да, я знаю, что это вообще не-нет, но в то время, когда был написан плагин, движок был монолитным двоичным и не мог делиться библиотеками.) В Windows все работает нормально. В Linux мы получали segfaults. Посмотрев на трассировку стека ошибки, она возникала в плагине при вызове функций в двойном имени класса. Это, по-видимому, было результатом того, что движок и плагин имели несколько разные версии общего кода (некоторые функции класса были закомментированы в плагине). Это было похоже на то, что плагин получал свои символы, связанные с движком, вместо собственного. Мы «исправили» проблему, изменив параметры dlopen на dlopen(pFilepath, RTLD_LAZY | RTLD_LOCAL).

Но когда мы переписывали движок, который должен быть разделен на разделяемые библиотеки (для возможной цели повторного использования в плагинах), мы снова получаем ошибку segfault. И, глядя на трассировку стека, он идет от движка -> плагин -> движок.

Есть ли способ указать для компоновщика времени выполнения не отображать символы плагина в движке (особенно если они определены в плагине)?

Спасибо! Matt

---

Edited 2009-12-3

Я первый попытался обернуть код плагина в его собственном пространстве имен. Это не сработало, потому что оно статически связано с библиотекой, которая также связана с движком. Варианты статической библиотеки разные, поэтому segfault!

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

У меня все еще проблема, так как есть параллельная версия программы (с использованием Open-MPI) и которая все еще получает segfault. Он появляется в том, что он все еще экспортирует символы двигателя и перемещает плагин. Это может быть связано с тем, как Open-MPI выполняет приложение.

Есть ли какие-либо флагов компоновщика, которые могут быть использованы в общей библиотеке плагинов, которые говорят, что это не приведет к динамическому перемещению символов во время выполнения? Или скрыть свои символы, чтобы они не переселились? Я пробовал -s («Опустить всю информацию о символах»), но это, по-видимому, не изменило динамические символы (проверено с использованием nm -D <plugin>).

Answer 1

Я думаю, что нашел решение, флаг компоновщика -Bsymbolic. По существу этот флаг добавляет флаг в общую библиотеку, чтобы сообщить компоновщику времени выполнения сначала попробовать сначала разрешить имена символов внутри себя. Двигатель мог работать с плагином просто отлично во всех случаях (монолитный exe, exe w/shared libs, плагин w/и без оболочки пространства имен), когда плагин был связан с этим флагом.

Там, кажется, несколько недоброжелателей с предупреждениями о -Bsymbolic:
http://www.technovelty.org/code/c/bsymbolic.html
http://software.intel.com/en-us/articles/performance-tools-for-software-developers-bsymbolic-can-cause-dangerous-side-effects/

Но учитывая их предупреждения и что намерение плагина, я думаю, что это правильный вариант для меня. По крайней мере на данный момент.

Answer 2

Я согласен с Glen - вы не собираетесь это решать, если вы не измените имена классов, возможно, через пространства имен. Даже 36 файлов, вероятно, потребуют меньше времени для изменения, чем попытки надежно исправить это, не меняя имен символов.

Начните с определения всех классов, имена которых должны быть изменены. Возможно, ваш компоновщик уже перечисляет их для вас. Тогда я бы изменил имена как наборов классов (от Foo до Engine :: Foo и Plugin :: Foo например) хотя бы временно.Таким образом, вы можете заставить компилятор найти все ссылки на проблемные классы. Откажитесь от источника плагина до компиляции плагина со ссылками на правильные новые имена классов плагинов. Как только это будет сделано, измените классы Engine :: назад на их старые имена (если вы не хотите постоянно изменять исходный код двигателя, который звучит так, как будто вы этого не делаете). Теперь плагин должен компилировать и ссылаться на правильные, уникально названные классы.

Answer 3

Я бы просто привязал ВСЕ код плагина к пространству имен PluginX. Это наверняка избавит вас от этих ошибок. В любом случае это очень хорошая, важная практика.