Здравствуйте!

Пишу разделяемую библиотеку для использования в качестве UDF.
Не проходит простой пример с таким фрагментом кода.



Библиотека работающая. Собирается без ошибок Если использовать ее не в UDF, а вызывать из простого тестового приложения, все проходит без ошибок. Без этих двух строк работает и как UDF.

В UDF на операторе delete возникает ошибка Segmentation fault.

Насколько понял в результате поиска, у Firebird свой менеджер памяти, а при сборке моей библиотеки new и delete автоматически экспортируются из библиотеки libstdc++. 

На форуме Firebird посоветовали указать линкеру не экспортировать из .so всё подряд.

Стал разбираться с параметрами компоновщика ld. Пробовал --no-export-dynamic,  --exclude-libs, никакого эффекта.
Ошибка та же самая. И таблица символов, выдаваемая по nm, остается без изменений.


Есть еще параметр --dynamic-list-cpp-new. Если его использвать, таблица символов также не меняется

Если кто-нибудь владеет этим вопросом, посоветуйте, пожалуйста, что можно сделать.

С уважением, Владимир.

------------------------------------------------
 
Ubuntu 10.04 LTS
g++ версии 4.4.3-4ubuntu5
libstdc++6

Попробуй использовать ключи компилятора и линкера -fvisibility=hidden -fvisibility-inlines-hidden, а так же линковать статически. Только имей в виду, что придется все экспортируемые функции/классы помечать специальным атрибутом.

Кстати, а может стоит использовать менеджер памяти Firebird?

Спасибо за совет, пробую!


Задал ключи -fvisibility=hidden -fvisibility-inlines-hidden.
В результате в таблице символов тип для моей функции TESTINSERT изменился с T на t, вызываться она перестала.
__attribute__((visibility("default"))) вернул все на место.

Но при всем этом 
         U _ZdlPv@@GLIBCXX_3.4
         U _Znwj@@GLIBCXX_3.4
из таблицы символов не уходят.


Чтобы линковать статически, достаточно задать ключ -static, или требуется что-нибудь еще?
Пробовал, но компоновщик не находит библиотеку libgcc_s.
Действительно, на диске имеется только so версия этой библиотеки.


Насчет использования менеджера памяти Firebird пока не смотрел.
Тестовая функция простая, но дальнейшая задача - запустить громоздкую библиотеку чужого кода.
Боюсь утонуть, если начну там что-то править.


С уважением, Владимир.

VladimirNi, ну х.з. тогда. Можно еще попробовать сделать финт: делаешь простую библиотеку на С, которая загружает основную библиотеку и все вызовы перенаправляет в нее...

Если этот менеджер находится в какой то .so, то подайте эту .so при линковке своей UDF. new и delete будут взяты оттуда

В Firebird есть библиотека ib_util, в которой определена функция ib_util_malloc. Эту функцию можно использовать вместо malloc.
Но у меня в UDF не malloc, а оператор new. Что с ним делать - непонятно.

С уважением, Владимир.

Написать свой new и delete

Попробовал сделать это на простом примере. Получается следующее.

Вариант 1. Без new и delete.

Такая UDF успешно отрабатывает.


Вариант 2. Ошибка с new и delete.

Ошибка Segmentation fault.


Вариант 3. Пытаюсь перегрузить операторы new и delete.

Ошибка Segmentation fault.


Если функция TESTINSERT вызывается не как UDF, а из обычной программы - все три варианта работают.

В чем может быть дело? 
Предполагалось, что после перегрузки new и delete вариант 3 сработает аналогично варианту 1.
Что еще можно попробовать?


С уважением, Владимир.

А вы проверяли что в этом случае вызываются именно ваши перегруженные операторы ?

Попробуйте ваши перегруженные new/delete описать как inline

Проверил.

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

При вызове UDF перегруженные операторы игнорируются.
Оператор new (не перегруженный) проходит без ошибки.
На операторе delete UDF падает.

С уважением, Владимир. 

К сожалению, ничего не изменилось.

С уважением, Владимир. 

Тогда как static. В общем, что бы из so не торчали ссылки на внешние new/delete

Ситуация разрешилась со стороны  Firebird.

Если подключаться не по локальному коннекту, а по сетевому, данная ошибка не проявляется.

Кроме того, для локального соединения разработчики планируют внести исправления.

Большое спасибо всем ответившим, наилучшие пожелания!

С уважением, Владимир.