iBase.ru Forum

Сервер IB 7.5.1

Эксплуатируется уже около года, периодически падал, сегодня анализирую логи: постоянно валятся ошибки:

Access violation.
The code attempted to access a virtual
address without privilege to do so.

или

An exception occurred that does
not have a description. Exception number EEDFADE.

Далее следует:
DB03_001 (Client) Thu Jun 19 13:10:28 2008
C:\Program Files\Borland\InterBase\bin\ibserver.exe: terminated abnormally (-1)

иногда перед ошибкой зафиксировано имя ХП или запрос, иногда пусто
часть ХП имеют обращение к UDF, часть нет, есть селективные ХП и запросы, есть исполняемые, процедуры к разным БД (сопровождается 5 БД).
Подскажите, что за беда и как бороться?
(AV полученная из UDF приводит к такой фигне и падению одназначно, проверено, но вот остальные, которые к UDF не обращаются...)

уже был такой вопрос. см. сюда:
http://forum.ibase.ru/phpBB2/viewtopic.php?t=2010

т.е. это стопудово ошибка в udf dll.

kdv писал(а): т.е. это стопудово ошибка в udf dll.

я написала в посте, что вызов AV в UDF нормально и стабильно приводит к такой ошибке и падению сервера, но тогда падали бы строго определенные процедуры вызывающие "плохую" udf меня как раз больше интересует вопрос почему вот это в логе:
OBOROT_GROUP_DATE2
Access violation.
The code attempted to access a virtual
address without privilege to do so.
This exception will cause the InterBase server

где OBOROT_GROUP_DATE2 имя ХП, которая просто выбирает данные из таблиц и ни к каким библиотекам не обращается. И почему эта процедура не отваливается при каждом запуске, а запускаться должна раз по 10 на дню точно, а шибок таких 4 за год.

Скорее всего какая-то UDF-ка портит память.
Тогда последствия могут проявиться когда угодно.

Tonal писал(а):Скорее всего какая-то UDF-ка портит память.
Тогда последствия могут проявиться когда угодно.

Как она это может делать? В каком направлении рыть код? Какие могут быть узкие места и можно ли выяснить какая именно UDFка?
Много у меня вопросов

Вот еще из известной статьи с этого ресурса:

Внимание!: для правильной работы UDF в IB 4.2 и 5.x в инициализации DLL должна быть обязательно написана фраза IsMultiThread:=True; В противном случае при одновременном вызове udf несколькими пользователями в interbase.log будут появляться сообщения об ошибке "SCH_validate - …", или возможна порча памяти сервера с неприятными последствиями для базы данных.

это для 7.5.1 справедливо?

SlyTanys писал(а):An exception occurred that does
not have a description. Exception number EEDFADE.

Однозначно - необработанное дельфийское исключение.

это для 7.5.1 справедливо?

это было всегда справедливо и для всех серверов ib/fb.

Подскажите пожалуйста еще одну вещь. IsMultiThread:=true должно быть указано для всех dll, или только для тех, которые используют глобальные переменные?

для всех. и глобальные переменные тут ни при чем. их, собственно, вообще не очень хорошо в udf использовать.

А еще можно вопрос? Как объявление IsMultiThread:=true в dll влияет на работу библиотеки с использованием выделения памяти через ib_malloc. И к чему приведет работа библиотеки с выделением памяти через ib_malloc без такого объявления.

($Delphi)\source\vcl

неясно, зачем копаться в потоконебезопасном этом самом.
суперсервер - это процесс с тучей тредов. которые могут вызывать udf.
следовательно, в udf должно быть написано isMultiThread:=True. Причем, это все равно не гарантирует потокобезопасность при вызове определенных функций RTL, WinAPI или своих функций, например обращающихся ... к глобальным переменным в UDF.

для классика все это необязательно.

и, насчет ib_malloc - эта функция введена не для мультитредовости, а для совместимости с рантаймом конкретного IB/FB, для функций с FREE_IT. Объясняется в FAQ.

>>An exception occurred that does
>>not have a description. Exception number EEDFADE.

>Однозначно - необработанное дельфийское исключение.

Еще такой вопрос, можно ли в функции UDF возбудить исключительную ситуацию и каким то образом обработать при вызове?

Еще такой вопрос, можно ли в функции UDF возбудить исключительную ситуацию и каким то образом обработать при вызове?

можно, но практического смысла нет. потому что обработать не получится. exception уйдет в код сервера. а что сервер должен с ним делать?
вообще такой вопрос косвенно означает, что Вы и exception обрабатывать не умеете, как и работать с dll.

Я вообще много чего не умею, поэтому задаю вопросы, если бы умела - не задавала, логично?
если вам нетрудно, то помогите мне еще немного:
про исключение я имела в виду следующее. В библиотеке есть функция, которая при неверном значении входного параметра возбужает исключительную ситуацию (raise). Если эту функцию вызвать с соответствующим значением параметра, то в логе сервера мы видим:

An exception occurred that does
not have a description. Exception number EEDFADE.
This exception will cause the InterBase server
to terminate abnormally.
ну и соответственно сервер падает.
Функция вызывается в обычном запросе select. Вопрос собственно, что можно сделать (и можно ли вообще), чтобы сервер при получении исключительной ситуации из dll не умирал?

Вопрос собственно, что можно сделать (и можно ли вообще), чтобы сервер при получении исключительной ситуации из dll не умирал?

ничего. exception в dll/udf для сервера это сигнал об ошибке. dll выполняется в сегменте кода сервера, поэтому дальнейшее продолжение работы опасно. И серверу все равно - exception возник случайно или намеренно.

решение одно - переписать udf, так чтобы никакие exception наружу не передавались.

SlyTanys писал(а):В библиотеке есть функция, которая при неверном значении входного параметра возбужает исключительную ситуацию (raise).

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

При чём тут параметры? EEFADE это грязная работа с памятью. Аффтару поможет только хороший отладчик (не в смысле - софт, а в смысле - человек).