Совместимость InterBase, Firebird, Yaffil между собой и по версиям
Модераторы: kdv, Alexey Kovyazin
-
v6y
- Сообщения: 78
- Зарегистрирован: 12 мар 2005, 17:45
Сообщение
v6y » 20 мар 2005, 19:07
Привет всем. Поставил себе Firebird 2.0.
Когда стал компилить свои програмулины с новой fbclient от FB 2.0, то получил предупреждение
../ibapi.c:30: warning: `isc_interprete' is deprecated (declared at
/usr/include/ibase.h:903)
Я так понял API будут меняться. И насколько сильно?
-
dimitr
- Разработчик Firebird
- Сообщения: 888
- Зарегистрирован: 26 окт 2004, 16:20
Сообщение
dimitr » 20 мар 2005, 22:21
совместимость старых приложений гарантирована. Пользоваться или нет расширениями API - решать тебе...
-
v6y
- Сообщения: 78
- Зарегистрирован: 12 мар 2005, 17:45
Сообщение
v6y » 21 мар 2005, 10:51
dimitr писал(а):совместимость старых приложений гарантирована. Пользоваться или нет расширениями API - решать тебе...
Linux Debian 3.0, LI-T2.0.0.10571 Firebird 2.0 Alpha 1
Есть у меня одна функция, вот ее фрагмент:
Код: Выделить всё
...
char msg[512];
...
if (status[0] == 1 && status[1]) {
isc_interprete(msg,(long **) &status);
*Error=msg;
msg[0]='.';msg[1]=' ';
while (isc_interprete(msg+2,(long **)&status))
*Error+msg;
}
...
Работала нормально со всеми FB до 2.0
В FB 2.0, если обрабатывается ошибка попытки соединения к несуществующей базе данных, то первый isc_interprete отрабатывает нормально, второй вылетает по "Segmentation fault". Остальные ошибки обрабатываются нормально. Далее, если заменить isc_interprete на новую fb_interpret, то все работает на ура.
Проверять кто нибудь будет? Или самому покопаться на досуге?
-
v6y
- Сообщения: 78
- Зарегистрирован: 12 мар 2005, 17:45
Сообщение
v6y » 21 мар 2005, 12:35
Или самому покопаться на досуге?
Не удержался, сам покопался, хотя и других дел по горло. Знаю теперь в чем проблема - повезло, что в остальных случаях обошлось без эксцессов. Если кому интересно, фиксится это дело установкой размера msg в моей функции в MAXPATHLEN*2 (у меня это msg[8192]) или использованием fb_interpret. Так что с совместимостью могут таки возникнуть проблемы.
-
dimitr
- Разработчик Firebird
- Сообщения: 888
- Зарегистрирован: 26 окт 2004, 16:20
Сообщение
dimitr » 21 мар 2005, 13:19
не совсем понял, причем тут совместимость. isc_interprete() не проверяет размер переданного ей буфера. И никогда не проверяла. Т.е. она всегда может вызвать SEGV при слишком маленьком подготовленном буфере. Именно из-за этого и ввели fb_interpret(), которая безопасна в этом плане.
Ты потенциально мог наткнуться на грабли даже при переходе на минорную версию (напр., v1.5.1->v1.5.2), если там изменялся текст сообщений об ошибках.
-
v6y
- Сообщения: 78
- Зарегистрирован: 12 мар 2005, 17:45
Сообщение
v6y » 21 мар 2005, 13:36
dimitr писал(а):не совсем понял, причем тут совместимость. isc_interprete() не проверяет размер переданного ей буфера. И никогда не проверяла. Т.е. она всегда может вызвать SEGV при слишком маленьком подготовленном буфере. Именно из-за этого и ввели fb_interpret(), которая безопасна в этом плане.
Ты потенциально мог наткнуться на грабли даже при переходе на минорную версию (напр., v1.5.1->v1.5.2), если там изменялся текст сообщений об ошибках.
Потенциально конечно мог, но размер в 512 байт фигурирует в примерах из API guide и количество данных, возвращаемых одним вызовом isc_interprete действительно никогда не превышало 512 байт (даже 100 по-моему) Поэтому если кто-то, как и я писал свои проги на основе примеров их API Guide, то может сразу же нарваться на подобные грабли. Поэтому предлагаю в функции safe_interpret в jrd/gds.cpp заменить
Код: Выделить всё
strncpy(s, q, bufsize);
s[bufsize - 1] = 0;
на что то типа
Код: Выделить всё
int i;
...
for (i=0; i<bufsize-1 && *q;) s[i++]=*q++;
s[i]=0;
Заменить придется всего в двух местах, если я чего-то не проглядел. Зато старые программы, декларирующие буфер, размером меньше MAXPATHLEN*2, валится будут только при очень длинном имени файла или алиаса базы данных.
-
v6y
- Сообщения: 78
- Зарегистрирован: 12 мар 2005, 17:45
Сообщение
v6y » 29 авг 2005, 15:17
Я прошу прощения, что опять поднимаю эту тему.
Реальная задача. Есть демонок, пишущий кое-какие логи в базу в режиме реального времени. При запуске пытается подсоединится к базе, в случае неудачи пишет в свой лог ошибку и тупо пытается самостоятельно эту базу создать и в случае повторной неудачи выходит.
Ну и естественно при использовании FB 2.0, isc_interprete и декларировании буфера размером 512 байт, это дело при попытке подсоединения к несуществующей базе (первом запуске демона) со свистом вылетает по SIGSEGV... И причина этому вот эти чудные строчки
так как bufsize здесь предполагается равным 8192, хотя фактически равен 512.
Уважаемые разработчики, может все таки слегка подправите код? Это ведь займет десять-двадцать секунд максимум...
-
dimitr
- Разработчик Firebird
- Сообщения: 888
- Зарегистрирован: 26 окт 2004, 16:20
Сообщение
dimitr » 29 авг 2005, 21:31
угу, помню, что обещал разобраться. Но в пылу борьбы с другими багами запамятовал. На неделе вернусь к этому вопросу и отпишу здесь свое резюме.
-
dimitr
- Разработчик Firebird
- Сообщения: 888
- Зарегистрирован: 26 окт 2004, 16:20
Сообщение
dimitr » 20 сен 2005, 14:42
хоть и не на неделе, но дошли наконец руки. Но увы, подтвердить проблему не смог. У меня на всех сочетаниях серверов и клиентов (1.5.x и 2.0), а также файлов firebird.msg сообщения об ошибках идентичные (в случае коннекта к несуществующей базе) и не превышают 512 байт.
Если можешь сообщить детальную инфу со своей машины - благодарствую. А именно, код ошибки в статус-векторе и полное сообщение об ошибке (полученное с бОльшим буфером). Этого мне хватит, чтобы либо разобраться, либо задать новые вопросы
ЗЫ. можешь писать сразу в мыло. Тут это уже никому не интересно, полагаю.
-
v6y
- Сообщения: 78
- Зарегистрирован: 12 мар 2005, 17:45
Сообщение
v6y » 21 сен 2005, 10:30
dimitr писал(а):
ЗЫ. можешь писать сразу в мыло. Тут это уже никому не интересно, полагаю.
Написал на твой sourceforge-вский адрес