— Может снимем девочек?
— Пусть еще повисят.
Вот уже несколько дней на тестовой машине висит пара окон:
Стек падения:
fbclient.dll!get_numeric_info(const char * * ptr=0x00000000) Строка 923 + 0x15 байт C++
fbclient.dll!UTLD_parse_sql_info(int * status=0x00000000, unsigned short dialect=2, const char * info=0x00000000, XSQLDA * xsqlda=0x1bbe4e10, unsigned short * return_index=0x0391f498) Строка 226 + 0x11 байт C++
fbclient.dll!iterative_sql_info(int * user_status=0x00000000, void * * stmt_handle=0x00000002, unsigned short item_length=62868, const char * items=0x10074764, short buffer_length=0, char * buffer=0x00000000, unsigned short dialect=1, XSQLDA * sqlda=0x1bbe4e10) Строка 5575 + 0x13 байт C++
fbclient.dll!isc_dsql_prepare(int * user_status=0x0391f7a0, void * * tra_handle=0x1c962398, void * * stmt_handle=0x1a7761d8, unsigned short length=26, const char * string=0x09b90f10, unsigned short dialect=1, XSQLDA * sqlda=0x1bbe4e10) Строка 3580 C++
_IBProvider_v3_vc14xp_i.dll!ib_v5::t_ib_statement_v5::prepare(db_obj::t_db_operation_context & op_ctx={...}, db_obj::t_db_stmt_result_kind stmt_result_kind=db_stmt_result_kind__selectable, structure::t_basic_const_str_box<wchar_t> stmt={...}, db_obj::t_db_row * const row=0x1b1e17c8, const unsigned int pr_flags=0) Строка 210 + 0xc2 байт C++
_IBProvider_v3_vc14xp_i.dll!ibp::t_ibp_command::prepare3(db_obj::t_db_operation_context & op_ctx={...}, db_obj::t_db_stmt_result_kind stmt_result_kind=db_stmt_result_kind__selectable, structure::t_basic_const_str_box<wchar_t> text={...}, const unsigned int expected_params_count=0) Строка 103 C++
_IBProvider_v3_vc14xp_i.dll!ib_sql_pstmt::t_ib_sql_pstmt_select_table::prepare_clone_impl(ibp::t_ibp_operation_context & op_ctx={...}) Строка 363 + 0x52 байт C++
_IBProvider_v3_vc14xp_i.dll!ib_sql_pstmt::t_ib_sql_pstmt_select_table::prepare_sql_impl(ibp::t_ibp_operation_context & op_ctx={...}) Строка 340 C++
_IBProvider_v3_vc14xp_i.dll!ibp_sql_pstmt::t_ibp_sql_pstmt_std_base::prepare_sql(ibp::t_ibp_operation_context & op_ctx={...}) Строка 116 C++
_IBProvider_v3_vc14xp_i.dll!ibp::t_ibp_command_pstmt_data::prepare(ibp::TIBPCommand * const pCommand=0x32d400c0, const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & command_text={...}, structure::t_smart_object_ptr<ibp::t_ibp_transaction,structure::t_sptr_traits<ibp::t_ibp_transaction> > & spTrans={...}) Строка 107 C++
_IBProvider_v3_vc14xp_i.dll!ibp::TIBPCommand::Prepare(unsigned long __formal=0) Строка 54 C++
ibp_oledb_test_vc14_Win32_Release_xp.exe!oledb_lib::t_db_command::prepare_ex(structure::t_str_parameter<wchar_t,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > text={...}, oledb_lib::t_db_row * pRow=0x00000000, unsigned long describe_flags=1) Строка 135 + 0x18 байт C++
Сегодня, наконец-то, решил посмотреть что там произошло.
Все ясно — в этот раз не повезло.
Вообще говоря, использовалась та же самая тестовая база данных. И, похоже, весьма удачная.
Если бы не опечатка в батнике, вместо fbclient должен был работать встроенный клиент для FB:
1. [LCPI.IBProvider.3]: [winsock] Ошибка определения сетевого адреса хоста [locahost][порт: 3050]. Ошибка WinSock: 11001.
2. [LCPI.IBProvider.3]: Ошибка подключения к базе данных.
Но ничего, сейчас запустим 🙂
Привет всем.
Медленно и печально продираюсь сквозь терни подключения к FB3 минуя fbclient.dll. Добрался до настройки шифрования подключения (op_crypt). Разобравшись что к чему, я даже немного оживился — если делать по уму, то конструкция получается достаточно красивой.
(далее…)
Привет всем.
Время от времени нагрузочное тестирование 32-битной сборки IBProvider-a (как правило, отладочной) начинает плющить и оно превращается в стрессовое — не хватает оперативной памяти. Выглядит это вот так:
(далее…)
Dmitry Kovalenko on 14 августа, 2016 | 1 Comment
Привет всем.
Сегодня, созерцая время выполнения тестов новой сборки (21500) c Firebird 2.5 немного опух — через fbclient.dll тесты отрабатывали в 5 раз быстрее чем через встроенный клиент. Подключение к серверу осуществляется через TCP/IP: localhost:d:\database\ibp_test_fb25_d3.gdb.
Результаты для fbclient.dll:
------------------------------------------- [SUMMARY INFORMATION]
[TESTS]
EXECUTED : 17407
SUCCEEDED : 17406
FAILED : 0
WITH WARNINGS : 1 [ 1 warning(s) ]
- - - - - - - - - - - - - - - - - - - - - -
TEST TIMES]
REAL : 4759506647 [00:07:55.9506647]
USER : 1640038513 [00:02:44.0038513]
KERNEL : 299209918 [00:00:29.9209918]
TOTAL : 1939248431 [00:03:13.9248431]
Результаты для встроенного клиента:
------------------------------------------- [SUMMARY INFORMATION]
[TESTS]
EXECUTED : 17407
SUCCEEDED : 17406
FAILED : 0
WITH WARNINGS : 1 [ 1 warning(s) ]
- - - - - - - - - - - - - - - - - - - - - -
[TEST TIMES]
REAL : 25232635350 [00:42:03.2635350]
USER : 1359080712 [00:02:15.9080712]
KERNEL : 267229713 [00:00:26.7229713]
TOTAL : 1626310425 [00:02:42.6310425]
Ну, думаю, приплыли. Раньше же такого не было.
После разбора полета обнаружилось, что встроенный клиент сначала пытается подключаться к серверу (FB2.5) через TCP/IPv6, а потом через TCP/IPv4. Из-за IPv6 задержка была такой, что спотыкание процесса выполнения тестов было видно невооруженным взглядом.
Я на эти попытки подключения через IPv6 уже обращал внимания, но не придавал им особого значения. Ну не смог подключиться, ничего страшного. А оказалось «чего».
После явного указания подключения через IPv4 (inet4://localhost/d:\database\ibp_test_fb25_d3.gdb) все нормализовалось.
Результаты перезапуска (на новой тестовой базе данных)
Для fbclient.dll:
------------------------------------------- [SUMMARY INFORMATION]
[TESTS]
EXECUTED : 17407
SUCCEEDED : 17405
FAILED : 0
WITH WARNINGS : 2 [ 2 warning(s) ]
- - - - - - - - - - - - - - - - - - - - - -
[TEST TIMES]
REAL : 3720155706 [00:06:12.0155706]
USER : 2020212950 [00:03:22.0212950]
KERNEL : 382202450 [00:00:38.2202450]
TOTAL : 2402415400 [00:04:00.2415400]
Для встроенного клиента:
------------------------------------------- [SUMMARY INFORMATION]
[TESTS]
EXECUTED : 17407
SUCCEEDED : 17405
FAILED : 0
WITH WARNINGS : 2 [ 4 warning(s) ]
- - - - - - - - - - - - - - - - - - - - - -
[TEST TIMES]
REAL : 3601447761 [00:06:00.1447761]
USER : 1941588446 [00:03:14.1588446]
KERNEL : 357242290 [00:00:35.7242290]
TOTAL : 2298830736 [00:03:49.8830736]
Так что, теперь надо будет себя приучать явно указывать версию TCP/IP в строке подключения. Во избежание.
Привет всем.
Основное изменение в коде OLE DB провайдера
Минимизация случаев, когда провайдер запрашивает тип SQL запроса у сервера (isc_dsql_sql_info, tag: isc_info_sql_stmt_type). Эти данные нужны самому нижнему уровню провайдера для определения «селективных» запросов. Внезапно выяснилось, что InterBase возвращает нулевой идентификатор для запроса «SAVEPOINT …» и это очень сильно удивляет IBProvider:
Меня, почему-то, это не очень сильно удивляет.
Сейчас тип запроса «подсказывается» собственным SQL-парсером провайдера.
По идее, это (до кучи) должно сократить время, затрачиваемое на подготовку запросов.
Привет всем.
Несколько месяцев назад решил поглумиться над клиентом Firebird (v2.5) — заставить его тупить минут 10 над коммитом. Сценарий простой — перед коммитом нужно выполнить 100500 раз execute-close для селективного запроса.
И ничего не получилось. Это меня расстроило и я полез смотреть — какого? Обнаруженное меня тоже расстроило. (далее…)
Привет всем.
Анонсировано новое исправление IBProvider-a.
Забавно, но уже в трех местах нашел идентичную багу — забываю написать return. И это навеяло эпизод из «Особенностей национальной охоты»:
— А я ему говорю, товарищ генерал, берите ниже. Он — бах, и мимо. Бах — мимо. Я уж потом сам стал стрелять.
— Михалыч и мимо?
— А меня это не удивляет. Я, кстати, давно за ним замечаю: не бьет зверя. Не бьет зверя. Стрелять — он стреляет, но так, просто так.
В первом случае (исправлен в 3.30.1) срабатывал ассерт. В релизе проблем не было.
А во втором и третьем (copy&paste) — провайдер неправильно определял код основной ошибки сервера.
if(!result2.null())
result2.value(); //нет return
if(!result1.null())
result1.value(); //нет return
//[2015-05-05]
//статус вектор содержит херню какую-то.
return ibp_fb_err__unexpected_error;
Вообще, я в таких случаях стараюсь писать так:
if(!result2.null())
result2.value(); //нет return
assert(result2.null());
if(!result1.null())
result1.value(); //нет return
assert(result1.null());
//[2015-05-05]
//статус вектор содержит херню какую-то.
return ibp_fb_err__unexpected_error;
Бага сразу бы вылезла.
Но, похоже, 5 мая 2015 меня явно что-то очень сильно отвлекало 🙂
Привет всем.
4 июня (2016-го), после того как закончил чертыхаться, перезапустил большое тестирование IBProvider и FB2.5.
Вчера была пройдена критическая точка, в которой произошло зацикливание. Окучено ~660 тысяч тестов.
Сейчас идет фаза «бесконечных» тестов, которые вряд ли доработают до конца — их там около 7 млн, а база уже опухла до 1.3TB (я точно знаю, что это не предел). Текущая статистика базы выглядит так:
Database "d:\database\IBP_TEST_FB25_D3_all.GDB"
Database header page information:
Flags 0
Checksum 12345
Generation 43808420
Page size 8192
ODS version 11.2
Oldest transaction 43643448
Oldest active 43643449
Oldest snapshot 43643446
Next transaction 43643456
Bumped transaction 1
Sequence number 0
Next attachment ID 141439
Implementation ID 26
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Jun 4, 2016 17:13:01
Attributes
Variable header data:
*END*
Сервер наработал 834 часа. Типа 34 календарных дня.
Будем посмотреть, какое событие наступит раньше:
— закончится место на разделе (всего доступно 3.6TB)
— тестовый процесс наработает 1000 часов (пока 549 часов)
Еще возможны варианты проблем с электричеством (типа, компьютер не сможет уйти в режим ожидания) или я опять укабаню весь процесс.
Начал медленно работать ноутбук? Разберите и почистите пыль!
Моему рабочему ноутбуку уже больше 4 лет. Последний раз внутрь него заглядывали больше трех лет назад. В последнее время что-то он стал тупить, хотя вроде есть и 16GB и SSD. Но все никак «руки не доходили» почистить его от пыли.
На прошедших выходных наконец-то этот вопрос был решен.
Первое на что я обратил внимание — ожил индикатор TurboBoost процессора.
А сегодня обнаружил, что сборка плюсовых проектов начала работать в два, В ДВА РАЗА(!), КАРЛ, быстрее.
Это просто праздник какой-то!
Dmitry Kovalenko on 21 июля, 2016 | 1 Comment
1. Вернулся из отпуска
2. Зашел отладчиком в исходный код fbclient.dll v3.0
3. Захотелось пожелать разработчикам сервера всего доброго, хорошего настроения и здоровья
