Stack Overflow on database shutdown

[slackwarwick]

Firebird 2.5, C++ Builder 6.0.
Пытаюсь научить свою программу обрабатывать потерю соединения с БД. Для этого после старта программы делаю shutdown базы, и ловлю ошибку в TpFibErrorHandler::OnFIBErrorEvent. Но похоже, что программа вообще не доходит до вызова моей процедуры обработки. Происходит цепочка вызовов:
TpFibErrorHandler.DoOnErrorEvent -> TpFibErrorHandler.DefaultOnError -> .InternalClose -> <ошибка при закрытии транзакций> -><ошибка при закрытии запроса> -> TpFibErrorHandler.DoOnErrorEvent -> TpFibErrorHandler.DefaultOnError ... и так далее, из-за чего возникает переполнение стека.

[slackwarwick]

Возможно, как-то не так прошла сборка компонента, потому что у меня наблюдаются явные проблемы с указателями (вместо одного события объекта базы данных может вызываться другое, например). Возможно, этот issue - часть этой проблемы.

[slackwarwick]

Попробовал на другой версии FIB, более старой (6.9.9), официально купленной в свое время - нет, другие проблемы ушли, а проблема с shutdown остается.

[slackwarwick]

В общем, я немного исследовал эту тему, и пришел к выводу, что с обработкой события SHUTDOWN у компонента FIB все несколько плоховато. Причем быстро это исправить пока непонятно, как.
Откуда берется бесконечная рекурсия:

В функции TpFibErrorHandler.DoOnErrorEvent сразу вызывается TpFibErrorHandler.DefaultOnError, в котором есть такие строки:

  if (IBErrorCode=isc_shutdown) and (FindDatabaseForObject(Sender)<>nil) then
   FindDatabaseForObject(Sender).InternalClose(True,True);

InternalClose внутри себя пытается закрыть транзакции и запросы, но при вызове TFIBQuery.Close опять же от базы приходит код ответа isc_shutdown, и генерируется ошибка, приводящая к вызову TpFibErrorHandler.DoOnErrorEvent.

Я попытался подавить ошибку isc_shutdown, заменив в TFIBQuery.Close проверку CheckStatusVector([isc_bad_stmt_handle, isc_dsql_cursor_close_err]) на проверку CheckStatusVector([isc_bad_stmt_handle, isc_dsql_cursor_close_err, isc_shutdown]) (и то же самое внутри TFIBQuery.FreeHandle).

Тогда бесконечная рекурсия не происходит, но и событие TpFIBDatabase.DoOnLostConnect тоже не вызывается, т.к. база уже закрыта.

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

Вот вроде бы в функции TpFIBDatabase.InternalClose есть параметр DBinShutDown, но он, кажется, нигде не используется.

[CyberMaxRu]

slackwarwick, я сделал ровно точно так же.