Доброго времени суток.

32-разрядный Firebird 2.5.2 Classic на 64-разрядном Windows server 2003.

Проблема такая - имеется довольно большой отчёт, для отладки сделано протоколирование через автономные транзакции.
По ошибке протоколирование оказалось включено в production версии.
Процедура, которая пишет в журнал - такая:




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



Ещё есть процедура dual,



Отчёт приводить не буду - он очень большой. Отчёт - это хранимая процедура, возвращающая значения через suspend.

В отчёте есть внешний цикл, скажем, по товарам, для каждого товара заполняются временные таблицы, выводятся данные по товару. Затем порождается исключение, которое отлавливается блоком on ... do. При этом происходит откат изменений во временных таблицах и благодаря этому предотвращается замедление отчёта по мере прохождения цикла по товарам.
Запись в протокол разбросана везде по коду.

Если не вызывать из отчёта процедуру prtkl_zapisat, то всё нормально. Если вызывать, то через какое-то количество вызовов
(не считал, но возможно, около миллиона) заканчивается память в серверном процессе - "unable to allocate memory from operating system".

Естественно, после обнаружения проблемы я отключил протоколирование в production и на этом неприятности закончились. Но осадочек остался - непонятно, в чём дело и где в следующий раз я подорвусь.

Раньше был Firebird 2.1, протоколирование было сделано через внешние таблицы. Не могу сказать, что я формировал логи такого размера, как этот, случайно получившийся, но, во всяком случае, проблем с нехваткой памяти не было ни разу за 3-4 года эксплуатации. Я грешу на автономные транзакции, но, в общем-то, наверное, на это нет достаточных оснований.

Блобов в отчёте вроде бы нигде нет. Во всяком случае (повторюсь) при отключённом протоколировании он работает совершенно нормально.

Что может быть не так?

Симонов Денис, kdv, возможно, что лишняя, но именно этот код дал у меня ошибку, привожу его для чистоты эксперимента. Про кусок с row_count я уже оговорил.
Триггеров нет. udf есть: mod - стандартная, c - из rfunc, listadd - есть на сайте.
Насчёт list - не знаю, как посмотреть, там ведь не один исходник, а целое дерево. Вроде нет, хотя это не 100%. Конкатенации блобов нет.

Особенность состоит вот в чём: отчёт выдаёт довольно много строк (точно не знаю, но думаю, не меньше 10000).
Если вызывается prtkl_zapisat, то он падает довольно рано (то ли на строке 4000, то ли на 400).

В общем, понятно, что я не ответил на ваши вопросы. Что, пытаться сделать маленький пример без моего отчёта?

Dimitry Sibiryakov, на 90% я уверен, что память кончалась в серверном процессе. Память там ограничена уж по меньшей мере разрядностью сервера Firebird, а физически памяти на железе навалом. По правде сказать, проблема была месяц назад, я её быстро "решил" отключением протоколирования (которое было не к месту в промышленной базе) и бросил в трекер. Сегодня проводил уборку в трекере и нашёл её. Сейчас некогда её воспроизводить повторно, т.к. до возникновения ошибки отчёт крутится примерно полчаса. Я наделся, это что-то очевидное и мне сразу на это укажут. Если неочевидное, видимо, придётся отложить до лучших времён.

Таблоид, вот этого я и хотел. Большое спасибо! При случае обновлюсь, а там посмотрим, повторится ли проблема.

> Да, и механизм намеренного вызова исключений с целью отката транзакции меня как-то смущает
Fr0sT-Brutal, только с помощью этого механизма удалось добиться приемлемой производительности. Этот механизм вполне законен и прописан в документации (во всяком случае, в книжке он описан). Другое дело, какие баги при этом могут оказаться затронуты. Но практика показывает, что этот отчёт был вполне работоспособен в течение нескольких лет с этим механизмом. Так что рекомендую :)