netwind,

дело не только в написании функции, но и в ее объявлении в SQL. У меня на сайте есть пример
http://www.ibase.ru/files/download/safeudf.zip
на pascal, с тремя вариантами объявления функций с возвращаемыми параметрами.

Так вот, если ты хочешь, чтобы функция аллокировала память под результат внутри себя, а ФБ его освобождал, то
- функция должна содержать вызов ib_util_malloc
- функция должна быть объявлена с возвращаемым параметром по FREE_IT.

Если же память аллокируется не под возвращаемый результат, то она должна освобождаться в этой же функции. Причем, аллокировать (и освобождать) память в этом случае можно любыми способами.

То есть, FREE_IT это как бы "дайте мне функцию, результат которой аллокирован известным мне способом, и я смогу эту память освободить". Поэтому использовать нужно только ib_util_malloc из ib_util, который скомпилирован тем же рантаймом, что и ФБ.
Если использовать просто malloc, то рантаймы могут не совпадать, и память может быть освобождена ФБ некорректно.

Кроме того, А в твоем коде (я не силен в С, могу ошибаться)


никакого аллокирования не происходит. Что будет в результате при попытке ФБ освободить возвращаемый результат, я не знаю (не помню уже).

netwindКод, вероятно, общеизвестный . Есть выделение памяти :
это чушь какая-то. См. выше - ib_util_malloc вызывается из либы ib_util, и в дистрибутиве ФБ есть как эта либа, так и ее заголовок ib_util.h.
netwindКуда теперь копать ?
исправить самодеятельность в ib_util_malloc.
ну напиши процедуру, которая вызывает такую функцию с рандомным (и пустым) результатом, миллионов 5-10 раз, и смотри на потребление памяти ФБ. Если утечка есть, значит дело табак.

netwindтам в том же ключе функции написаны. например такое :
В оригинальном udflib.c написано вот так



и ib_util_malloc именно тот, который из ib_util.dll/ib_util.so.
Если даже брать udflib.c от IB4, то там код другой (free_it еще не было). А в ИБ5 уже free_it.

netwindchar* buf = (char *) ib_util_malloc(strlen(s) + 1);
RETURNS CSTRING(2000)
free-it тут нет, а память под возврат аллокируется в функции, и фактически замещает то, что ожидает получить ФБ.
Вы почитайте safeudf.dpr из файла по ссылке выше. Я там все расписал предельно просто и понятно.

В этой вашей upcase при такой декларации (без free_it) нужно модифицировать входную переменную, и ее же возвращать.
netwindНадо думать, неспроста такие декларации были сделаны - пакеты не смогли поставить, например.
какие еще пакеты?

А насчет того, почему падает - у вас объявление функции кривое, как мне кажется. Например
udflib.c - char* EXPORT fn_lower_c(char* s)
fbudf.c - FBUDF_API void getExactTimestamp(ISC_TIMESTAMP* rc)
где
#define FBUDF_API __declspec(dllexport)

а у вас - просто char * upcase(const char *s)

и все. где явное указание типа вызова?

netwindОткуда взялась эта манера передекларировать malloc - не понятно.
откуда вообще взялась манера писать отсебятину в udf. :-) Есть же правила, которые давным-давно написаны. Если правила непонятны, то надо использовать готовые примеры (официальные или однозначно рабочие) как болванки.

netwindБиблиотека долго мигрировала между версиями. Потери памяти ведь небольшие и годами этого не замечали.
еще добавлю - такая ситуация как у вас, встречается не впервые. Например, кривой тип вызова (stdcall вместо cdecl) в udf на delphi мог не приводить ни к каким фатальным результатам. А начиная с определенного момента - переезд сервера на другую ОС или на новую версию ФБ, или даже просто на сервер добавили памяти или поставили другой софт - хлоп, и или сервер начинает падать, или функция возвращает мусор из памяти.

netwindОднако, я поискал и обнаружил старую версию в ветке 2.5 . Там тот самый malloc ! Это не фантазия разработчика, а официальный пример для 2.5
кстати, да, подтверждаю, у меня в дистре 2.5 тот же ужас в udflib.c. Это кто-то проехался search/replace.
netwindТо есть, объявление типа бессмысленно
тогда не знаю.
Вот другой пример, из ib_util.h


netwindКакие современные примеры на C лучше посмотреть ?
fbudf, rfunc.