Боюсь нарваться на критику, но все-же рискну спросить...
После перевода большого проекта 2Тб, ~300 коннектов на базу с FB2.5 (x86 classic) на FB3 (x86 classic) столкнулись с проблемой завиcания всех процессов при обращении кого-то к MON$ таблицам из под RDB$ADMIN (предположительно). Как таких обращений с ХП (тем более на триггерах) к ним нет, но есть несколько системных процессов, стартующих с планировщика раз в пол часа и собирающих статистику долго работающих запросов и транзакций.
Если в этот момент еще кто-то параллельно (под RDB$ADMIN) хочет отменить запрос или закрыть чужой коннект, получаем либо жуткие тормоза при обращении к MON$, либо зависание "всего и вся".

Стек любого из "зависших" процессов, но он наверное, бесполезен


Из особенностей: Есть триггер на on_connect и on_disconnect, в котором имеется обращение к контекстным переменным и запись в журнал (таблицу) начала/конца пользовательской сессии с другими атрибутами, полученными с контекстных переменных.
На 2.5 за все время эксплуатации таких проблем не было, даже при наличии триггера на on_connect с обращением внутри него к mon$. При переходе mon$ заменили на контекстные переменные.

Виснет не всегда, но закономерности определить не смог, единственное что при таком зависании всегда есть fb-процесс, который грузит ядро процессора на ~ 100%.
Пока отключил шедулеры и запретил другим разработчикам обращаться к mon$

Куда копать и на что еще обратить внимание?
Спасибо.

MON$ таблицы видимо тут не причем (

Опять зависло все.
В логах кроме INET/inet_error: read errno = 10054
такая вот ошибка:


При BugcheckAbort = 1 в логах винды следующее
---------------------------------------------------------
Имя сбойного приложения: firebird.exe, версия: 3.0.8.33463, метка времени: 0x6090a204
Имя сбойного модуля: Engine12.DLL, версия: 3.0.8.33463, метка времени: 0x6090a1cb
Код исключения: 0xc0000090
Смещение ошибки: 0x0016b41a
Идентификатор сбойного процесса: 0x4c94
Время запуска сбойного приложения: 0x01d747e007cc9569
Путь сбойного приложения: C:\Firebird3\firebird.exe
Путь сбойного модуля: C:\Firebird3\plugins\Engine12.DLL
Идентификатор отчета: 6b9570d8-b3d3-11eb-80c8-e4434b212a35
Полное имя сбойного пакета:
Код приложения, связанного со сбойным пакетом:
---------------------------------------------------------
Беглый поиск 0xc0000090 привел к
https://support.microsoft.com/en-us/topic/fix-you-receive-an-error-message-or-an-exception-when-you-compile-or-run-an-application-that-has-some-compiler-options-turned-on-in-visual-studio-2008-sp1-642c9d1b-4634-ae29-bf23-49d328e76aae
но что с этой инфой делать не ясно (

Дамп памяти, и стеки во вложении
https://drive.google.com/file/d/1j6kyvdQwqv6iTCGnfGUmnUfNl_ABlUIm

Также замечено падение UDF, написанных на Delphi (на 2.5 не падали) на функции trunc.
Гугл приводит к такому:
https://stackoverflow.com/questions/22210233/invalid-floating-point-operation-calling-trunc

О падении УДФ с зависанием сервера я уже поднимал тему, и Влад правил
https://www.sql.ru/forum/1335563/zavisanie-padaushhego-processa-firebird3

P.S. Windows Server 2012 R2 Standart
CPU: Interl Xeon Gold 6136
Firebird x86 3.0.8.33463

Та это все хорошо и понятно, но...
У нас 3-ка используется давно, но на других базах, более мелких (гиг по 500...700) и с меньшей нагрузкой и проблем не наблюдалось.
Перевод крупнейшей базы тянули до последнего и 2 недели тестировали и вот перевели на свою голову...
Бог с тем падением удф, найдем причины и утечки, если они конечно же есть, хоть были написаны 100500 лет назад, пережили разные версии FB: interbase -> yaffil -> 1.5 -> 2.1 --> 2.5
Но 300 других коннектов лочатся, останавливается вся работа, процессы снимаются только через terminate, что чревато....
На обычных вызовах удф не падает, падает при сложной отработке кучи триггеров с использованием удф внутри них.

P.S. Предрекая упрек в неправильном выборе СУБД для таких объемов при таких кривых руках скажу:
В работе используем не только Firebird, но и другие СУБД, например Postgress с 12Тб базой.

Именно из-за сложных удф, которые написаны 100500 лет назад. Если было бы так просто перейти на х64, давно бы там были.
Понемногу юзаем udr на других базах.