Запустил «взрослое» нагрузочное тестирование с участием нового пула подключений на FB3. По ошибке — с участием fbclient.dll. Обнаружил это через пару часов после запуска, но решил — ладно, «нехай».
64-бита проехало без проблем.
32-бита встало по AV.
(далее…)
Всем привет.
1. Из личного кабинета можно скачать новый релиз IBProvider — 3.40.0.25216. Изменения:
2. В FB3 исправлена пара критических багов, которые вылазили при нагрузочном тестировании IBProvider:
Имеет смысл обновиться до FB3.0.3.32714.
3. Медленно и печально пилится собственный пул OLE DB подключений (для замены стандартного из oledb32.dll). В целом уже работает. По функционалу осталось только реализовать загрузку UDL-файлов.
Доступен для скачивания новый IBProvider Trial с исправленной ошибкой в libtommath.
Это была моя бага. Исправление можно посмотреть здесь.
Как оказалось, чтение за последним элементом массива в mp_div, это не бага, а фича неотъемлемая часть алгоритма.
Пришлось вернуть назад условие, модифицированное в декабре 2016 года. И немного по другому решить первоначальную проблему (см. get_safe).
—-
Отсутствие ассертов и халатная работа с памятью в оригинальном коде libtommath реально угнетает.
В FB3 затащили внешнюю библиотеку для работы с большими числами — libtommath. Затащили как есть. Только за это хочется взять черенок от лопаты…
(далее…)
Вышла и доступна для скачивания!
Скачал, поставил, перекомпилировал IBProvider.
Работает!
Неделю назад обнаружил, что нагрузочное тестирование 32-битной сборки зависло. Причем висит уже около суток. Состояние процесса показывало, что процесс в пике выедал практически все 4GB адресного пространства. Я было собрался просто убить процесс отмахнуться – «ну бывает, да», но потом решил, что такой подход ни к чему хорошему не приведет. И подключился к тесту отладчиком.
(далее…)
В новый триал (v3.38.0.25055) внесены следующие изменения и исправления:
1. Реализован контроль длин названий объектов в XSQLVAR (relname_length, sqlname_length, aliasname_length). До этого было обрезание при превышении максимального значения (32 или 68 байт) и обнуление отрицательного значения. Так что если серверный клиент вернет в этих полях некорректное значение, то теперь провайдер будет ругаться.
(далее…)
Сегодня один наш турецкий друг прислал замечательную ошибку, полученную при работе через собственный FB-клиент провайдера (dbclient_type=fb.direct).
Bug check at [RemoteFB__P12__XSQLDA_Utilities::Helper__ReadString] [#003]: the size [33] of the resulting data [tag: isc_info_sql_alias] is larger than the buffer size [32]. [Subsystem: remote_fb.p12] XSQLVAR information raw-data processing error. Index: 8. Failed to build the definition of statement result. Failed to obtain descriptions of the columns.
Говорит — с gds32.dll такой проблемы нет.
Связанный кусок SQL запроса:
STOKMIKTAR1.ASGARININALTINDA "İ.Stok Asgari Miktarın Altında",
Ответил, что gds32.dll обрезает строки, а провайдер обрабатывает строки (которые не влазят в XSQLVAR) как ошибки. И сообщил о своих мыслях избавиться в собственном клиенте от XSQLDA/XSQLVAR.
Связанный кусок кода из исходников 2.5:
//Тут помимо обрезания - есть еще пара проблем.
static SSHORT get_string_info(const SCHAR** ptr, SCHAR* buffer, int buffer_len)
{
const SCHAR* p = *ptr;
SSHORT len = static_cast<SSHORT>(gds__vax_integer(reinterpret_cast<const UCHAR*>(p), 2));
// CVC: What else can we do here?
if (len < 0)
len = 0;
*ptr += len + 2;
p += 2;
if (len >= buffer_len)
len = buffer_len - 1;
if (len)
memcpy(buffer, p, len);
buffer[len] = 0;
return len;
}
Правда сначала я начал искать в FB3 и нашел там такой замечательный код:
TEXT aliasbuffer[100] = "";
const TEXT* aliasname = aliasbuffer;
if (alias.hasData())
{
int length = alias.length(); //ну что это за херня, Карл?
if (length > 99)
{
length = 99;
memcpy(aliasbuffer, alias.c_str(), length);
aliasbuffer[length] = 0;
}
else
aliasname = alias.c_str();
}
else
aliasname = "<unnamed>";
Самое грустное — в IBProvider до сих пор присутствует подобный код. Хотя я последние несколько лет веду упорную борьбу с этими багами.
Вот кто бы лет двадцать назад сразу объяснил что так делать нельзя 🙁
В настоящее время идет достаточно злобная массированная ревизия и переработка относительно старого кода, связанного с управлением OLE DB свойствами.
В процессе обнаруживаются баги, дыры и костыли. Про первое и второе говорить особо смысла нет. А вот про третье — можно 🙂
Удалено свойство инициализации «free_threading«, которое влияло на значение информационного свойства «Data Source Object Threading«.
(далее…)
Все начиналось достаточно безобидно — я поправил в описании информационного свойства «Maximum Row Size» значение с 65536 на 65565.
Потом сообразил, что надо бы поправить эту константу в коде IBProvider.
Потом пришла мысль, которая должна была прийти в самом начале — «надо бы посмотреть на сайте FB». Посмотрел.
Maximum row size = 64KB
Maximum number of columns per table = Depends on data types used. (Example: 16,384 INTEGER (4-byte) values per row.)
А потом решил таки проверить все это самому на Firebird 3.0.2.32651.
(далее…)