Большое спасибо за указанные ошибки, UDF переделаю.
Но база с UDR, последний билд, SS - падения никуда не делись.

Дамп памяти не сохраняется, винда не видит что приложение крашится (в журналах винды нет сообщений о сбоях) - т.е. дамп во время сбоя снять не могу.

По итогу:
Ошибка не отлавливается, причина неизвестна, решения нет - вернулся на 2.5.

Dimitry SibiryakovСимонов ДенисАвтор даже не потрудился
Он даже проблему локализовать не потрудился. Зависания у него "внезапно" обернулись крашами.

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

Комбинации факторов из-за которых может происходить - код клиента, база, udf/udr, настройки fb, настройки сервака, железо. Каждый фактор пришлось исключать тестами.

Это на фоне ежедневных падений рабочей базы со всеми их последствиями.

Так что обратился за помощью когда собрал исходные данные и не смог сам локализовать проблему.
Поэтому эти групповые "даже не потрудился ..." - мне кажутся не в тему.

По существу:
Валится даже когда udf/udr не задействованы, поэтому я исключил их из причин.

Ошибка по udf промелькнула единственный раз в логе и больше ни разу не повторялась.
Тем более эта udf проработала 4 года на 2.5 без падений.

Я запускал udf 30 млн раз, расход памяти у firebird.exe не менялся (на классике).
Вообще сколько указываю DefaultDbCachePages - столько памяти отъедает и не меняется.

С зависанием.
Я в начале описал что в какой последовательности происходит.

Dimitry Sibiryakov

при этом тоже зависает или выдаёт результат?

С такими ключами не пробовал, а с "-d -L" и "-d -n" выдавал результат.

Симонов Денисзапуск кривой udf на классике и на супере дают совершенно разные результаты. В классике в случае чего отвалится только один коннект, в супере отвалятся все коннекты. Опять же поскольку коннекты у тебя в воркерах короткие, то и процессы классика долго жить не будут и могут не успеть загадить память, система всё равно вычистит не освободившуюся память при смерти процесса. С супером же у тебя проблемы будут накапливаться как снежный ком.
У меня на классике один коннект выдает ошибку, после этого новые коннекты не делаются - они молча висят (и не коннектятся, и не выдают ошибку), пока не закрываю все старые (работающие) коннекты и не перезагружаю главный.

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

Dimitry SibiryakovНе возвращается он. Процедуру обратной миграции не осилил.
Он осилил.
Правда это заняло пол ночи, т.к. и база большая, и получилось с третьего раза.

Dimitry Sibiryakovdb20mlnУ меня на классике один коннект выдает ошибку
Какую ошибку? Точный и полный текст - В СТУДИЮ!!!

Вроде бы все описал в начале:
У одного из воркеров (только у одного) при этом выскакивает ошибка:
firebird Attachment::start Transaction failed when loading mapping cache

Иногда ошибка:
Your user name and password are not defined. Ask your database administrator to set up a Firebird login.

В логах при этом возникают ошибки - обычно 2 подряд:
Database: C:\PROGRAM FILES\FIREBIRD\FIREBIRD_3_0\SECURITY3.FDB
page 0, page type 1 lock denied (216)

Database:
page 0, page type 1 lock denied (216)

Dimitry SibiryakovПри чём "при этом"? Какой именно вызов приводит к ошибке? У тебя что, каждый этап
производится в новом коннекте?..

Да, этапы идут последовательно. Сперва воркеры делают первый этап, затем пауза, потом второй, потом третий.

Dimitry Sibiryakovdb20mlnfirebird Attachment::start Transaction failed when loading mapping cache

И, кстати, этот текст несколько отличается от того, что я вижу в исходниках:
1) Нет "firebird" в начале;
2) Сервер говорит "IAttachment::startTransaction".

Ты уверен, что это сообщение - точное?..

Я по началу сохранял сообщения в текстовый файл, возможно слово firebird приписал сам а букву I удалил в спешке.

Но на последней сборке было вот такое сообщение (проверил по скриншоту):
page 0, page type 1 lock denied
IAttachment::startTransaction failed when loading mapping cache.