Выпуск следующего обновления IBP v5.7 немного затянулся. Что-то я закопался с устранением мелких проблем, в которые меня тыкает компилятор.
Изменений внесено достаточно много, но как обычно — помнишь только последнее.
Последним было решение проблем компиляции IBProvider (vc16/vs2019) с включенным злобным режимом «Conformance Mode=Yes». Спасибо коллективному разуму и rg45 лично.
Пока писал, вспомнил про другие глобальные изменения.
1. Переезд «сборочного процесса» с make.exe (борланд/эмбаркадера) на msbuild.
2. Обнаружил и задействовал опцию компилятора «Enable Function-Level Linking» (/Gy). Бинарники ощутимо похудели. На производительности вроде не отразилось.
3. Вместе с провайдером будут еще обновлены «LCPI Ole Db Services».
Релиз v5.7 будет через неделю. Максимум через две. Пора уже закругляться 🙂
Сдается мне, этот сервер достиг своего идеального состояния.
Только что загруженный «Developer Edition» полностью идентичен тому, который я скачивал 2018-12-13 (InterBase 2017, v13.3).
Amen.
UPD [2019-11-18]. Ан нет, шевелится — InterBase 2020. Смотрю на ссылку, а она не https. Походу, с ресурсами у них как у всех.
После прогона номинальных тестов IBProvider с FB2.5.9, обнаружил в логе сервера множество записей вида
VXP2-FB02-5-9 Sat Sep 28 22:09:35 2019
SERVER/process_packet: connection rejected for DIMA.-1.-1
Ошибок на уровне самих тестов не наблюдается.
После непродолжительного ступора, сообразил — это небольшие проблемы подключения к серверу через собственного клиента FB.
Он сначала пробует подключаться с использованием 13-го протокола. А потом предлагает подключиться через «12,11,10».
Можно было сразу предлагать «13,12,11,10», как это делает fbclient.dll, но там есть вопросы к надежности.
Для избежания «промахов» с 13-ым протоколом в строке подключения можно явно указать используемый протокол — 12.
А для устранения «промахов» с TCP/IP v6, которые нигде не отображаются, но приводят к тормозам подключения, надо еще явно указать использование TCP/IP v4.
То есть, строка подключения должна выглядеть приблизительно так:
location=inet4://server_name/d:\database\employee.fdb;remote:protocol=12;
Выпущено обновление .NET провайдера v1.14.1.
Как говорится — «нет худа без добра».
В процессе разбора проблемы с VS2019+FW4.8, нашел мелкую багу в одном из VSIX и, главное, радикально перетряхнул EXE-инсталлятор провайдера.
Если не ошибаюсь, он (EXE-инсталлятор) был написан пять лет назад. Как он работает — я уже ахез. Его какой-то мутант написал… Но сейчас (после перетряхивания) хоть станет попроще добавлять поддержку новых версий FW.
В последней VS2019 (16.2.5), после установки .NET FW4.8, перестал работать просмотр данных таблиц через наш ADO.NET провайдер. Server Explorer -> любая таблица -> контекстное меню -> загрузить данные -> пустое окно.
До установки FW4.8 (на FW4.7.2) проблем не было.
Это плохая новость.
Хорошая новость — через стандартный провайдер (System.Data.OleDb) просмотр данных тоже перестал работать.
Нужно звонить в ЖЭК и оставлять заявку.
В детстве меня покусал Джеф Рихтер, поэтому я свято верил в то, что Interlocked-функции экспортируются системной DLL-ю.
В сгенерированный машинный код для вызова этих функций я не заглядывал.
Как следствие, я считал что версии для 64-битных чисел на старой WinXP не поддерживаются и использовать их нельзя…
Этому способствовало и описание этих функций. Например, InterlockedExchange64:
Minimum supported client Windows Vista [desktop apps | UWP apps]
Minimum supported server Windows Server 2003 [desktop apps | UWP apps]
Target Platform Windows
А тут внезапно обнаружилось, что эти функции (по большому счету) не экспортируются, а встраиваются в точку вызова.
Это радикально все меняет!
return static_cast<_Ty>(_InterlockedIncrement64(_Atomic_address_as<long long>(this->_Storage)));
000000013F40ABC2 mov rcx,qword ptr [this]
000000013F40ABC9 call std::_Atomic_address_as<__int64,std::_Atomic_padded<unsigned __int64> > (013F3FA5CCh)
000000013F40ABCE nop
000000013F40ABCF mov ecx,1
000000013F40ABD4 lock xadd qword ptr [rax],rcx
000000013F40ABD9 inc rcx
000000013F40ABDC mov rax,rcx
Приведенный код нормально отрабатывает на 32-битной XP SP2.
Написал бы Рихтер про это в своем третьем издании «Win для Pro» — я бы 20 лет не тупил.
В процессе реорганизации кода получил 4 ошибки компиляции:
Ошибка C2065 ibp_task_controller_state__cancelled: необъявленный идентификатор
Ну, думаю, приплыли. Смотрю первый случай:
(далее…)
Собственно %subj%.
Было море адреналина и непрекращающийся допаминовый резонанс.
Я рад, что эта дата отмечается с пятой версией IBProvider на руках 🙂
Не знаю, что там случилось с сервером FB3.0.4 (а может с базой), но тесты заклинило и в firebird.log вижу следующее:
HOME4 Mon Aug 12 08:28:46 2019
Database: D:\DATABASE\RAM\IBP_TEST_FB30_D3_2.GDB
internal Firebird consistency check (pointer page vanished from DPM_next (249), file: dpm.cpp line: 1904)
HOME4 Mon Aug 12 08:28:46 2019
Database: D:\DATABASE\RAM\IBP_TEST_FB30_D3_2.GDB
internal Firebird consistency check (pointer page vanished from DPM_next (249), file: dpm.cpp line: 1904)
HOME4 Mon Aug 12 08:29:47 2019
I/O error during "WriteFile" operation for file "D:\DATABASE\RAM\IBP_TEST_FB30_D3_2.GDB"
Error while trying to write to file
Неверный дескриптор.
HOME4 Mon Aug 12 08:29:47 2019
Database: D:\DATABASE\RAM\IBP_TEST_FB30_D3_2.GDB
I/O error during "WriteFile" operation for file "D:\DATABASE\RAM\IBP_TEST_FB30_D3_2.GDB"
Error while trying to write to file
Неверный дескриптор.
Оставлю это здесь.
Dmitry Kovalenko on 12 августа, 2019 | 1 Comment
Вчера закончился прогон всех тестов, применимых к IBProvider v5 и Firebird v3. 27 дней, Карл.
Тестировался FB 3.0.4 (Win, x64, SuperServer). Официальная сборка с firebirdsql.org. С FB v3.0.5 почему-то не сложилось — файл базы данных выжирал все доступное место на рам-диске (80GB) и кино заканчивалось. Я три недели «помучался» и откатился на 3.0.4. Возможно я где-то что-то не то сделал…
В предыдущий раз тоже «мучался» FB3.0.4. Но сейчас тесты гонялись на IBProvider v5, Win10 (1809+) и у процессора включен HT (я его включил после обновления биоса). (далее…)
