iBase.ru Forum

Приветствую уважаемые.
Ситуация: ОС Linux SuSE 10 x64, стоит FB из rpm, запускается через xinetd, периодически падает. firebird.log - пустой. в messages сообщения вида : Apr 27 12:21:26 rein kernel: fb_inet_server[2328]: segfault at 00002aaaac1ae000 rip 00002aaaaad78812 rsp 00007fffffee1ef0 error 4
запросы простые, ни процедур, ни чего другого кроме данных. Падения бывают как на commit - Warning: ibase_commit(): Unable to complete network request to host "localhost". Error reading data from the connection. in script-name, так и на select - Unable to complete network request to host "localhost". Error reading data from the connection.
SELECT count(OFFERS.OFFER_ID) AS ALL_COUNT FROM OFFERS, REQUESTS, RFQ_OFFERS WHERE RFQ_OFFERS.OFFER_ID=OFFERS.OFFER_ID AND REQUESTS.REQ_ID=RFQ_OFFERS.REQ_ID AND REQUESTS.REQ_ADD_USER = 1 AND RFQ_OFFERS.OFFER_READ=0 ; Железо нормальное, проверялось.
Вопрос: как отследить состояние субд в момент падения - знаю, что есть пакет debug, не знаю как его использовать. firebird.conf не правился, разработчик говорит - значения по умолчанию достаточны, и у него все работает, но на 1.5.2. И что еще можно предпринять в данной ситуации?
P.S. gbak и gfix базы отрабатывают без ошибок.

Поставь в конфиге BugcheckAbort = 1 (не забудь раскомментировать).
При падении должен получиться core dump (или как там его в линуксах зовут).
Его можно (нужно) выслать мне (hvlad at users . sourceforge . net) или ДЕ или написать напряую в fb-devel

выставил в конфиге BugcheckAbort = 1, расскоментировал естественно.
Но дампов нет. Права на рабочий каталог у пользователя, от которого работает Firebird, есть. conf файл похватывает, проверялось по TcpNoNagle, при параметре равном "1" в firebird.log сообщение "inet server err: setting NODELAY socket option". СУБД падала опять на commit -
kernel: fb_inet_server[12137]: segfault at 00002aaaac12a000 rip 00002aaaaad78812 rsp 00007fffff8d0050 error 6

В продолжение темы. Похоже дело не в Firebird. На мысль навело отсутствие дампов и неработоспособность БД на другом сервере (FreeBSD, Firebird 1.53 из портов). На freebsd дело было в превышении количества запросов к inetd в единицу времени. Т.к. Fb работал как CS то работал он через inetd. Я думаю, что на SuSE была похожая проблема. Покапаюсь с xinetd, посмотрим какие будут результаты. Наверно это уже оффтопик здесь, поэтому если интереса в этой ветке проявлено не будет, то и продолжения истории тоже.