В одном из предыдущих постов ("Кто такой Auto?") я рекомендовал отключить Лог сервера, в случае не использования. И вот нашёлся ещё один повод. Наблюдая за сообщениями "Process Monitor" (где найти и как настроить см. пост "Lib.ldb") я заметил странную последовательность. Её легко воспроизвести следующим образом. Запускаем "Process Monitor", настраиваем его на PID Z-сервера. Запускаем "Администратор", подключаемся к любой базе, переходим на вкладку "SQL" набираем абракадабру
и выполняем запрос. Ты уже понял, что нам нужно просто сгенерить ошибку. Смотрим "Process Monitor".
Находим длинннннную последовательность обращений к файлу "EServer.log" - "Быстрые" операции запроса информации о файле и такая же "Быстрая" операция записи. То, что обращения происходят "Быстрым" ("Fast") методом это хорошо. Но почему записи идут ПО ОДНОМУ БАЙТУ? Инкремент смещения так же соответствует одному байту (см. выделение). Не иначе как запись сообщения об ошибке идёт по одному байту! А куда спешить? Не надо ошибаться.
Можно взглянуть на стек (на его кусочек; у меня x64, в x32 будет по-другому)
Строки обозначенные "U" - пользовательский режим, "K" - режим ядра. Значить при выводе каждого символа происходит пересечение границы ядра ОС. Но главный вопрос - выполняется ли физический сброс данных на диск при каждой операции ввода-вывода, пока остаётся открытым. Простой инструмент для проверки этого мне не известен, а лезть отладчиком в ядро - занятие не для слабонервных. Да и "игра не стоит свеч". В любом случае пересечение границы ядра ОС при выводе каждого байта "бесценной" информации об ошибке достаточный повод для того, чтобы его просто отключить.
И ещё один главный вопрос - кто виноват? В стеке фигурирует стандартная "Студийная" библиотека времени выполнения msvcrt.dll. По-видимому, это её работа. А если учесть, что в системе может быть установлена произвольная версия этой библиотеки...
Но это уже тема для отдельного поста. Как всегда пиши комментарии (регистрация не требуется) или на почту acbib3@yandex.ru.
и выполняем запрос. Ты уже понял, что нам нужно просто сгенерить ошибку. Смотрим "Process Monitor".
Находим длинннннную последовательность обращений к файлу "EServer.log" - "Быстрые" операции запроса информации о файле и такая же "Быстрая" операция записи. То, что обращения происходят "Быстрым" ("Fast") методом это хорошо. Но почему записи идут ПО ОДНОМУ БАЙТУ? Инкремент смещения так же соответствует одному байту (см. выделение). Не иначе как запись сообщения об ошибке идёт по одному байту! А куда спешить? Не надо ошибаться.
Можно взглянуть на стек (на его кусочек; у меня x64, в x32 будет по-другому)
Строки обозначенные "U" - пользовательский режим, "K" - режим ядра. Значить при выводе каждого символа происходит пересечение границы ядра ОС. Но главный вопрос - выполняется ли физический сброс данных на диск при каждой операции ввода-вывода, пока остаётся открытым. Простой инструмент для проверки этого мне не известен, а лезть отладчиком в ядро - занятие не для слабонервных. Да и "игра не стоит свеч". В любом случае пересечение границы ядра ОС при выводе каждого байта "бесценной" информации об ошибке достаточный повод для того, чтобы его просто отключить.
И ещё один главный вопрос - кто виноват? В стеке фигурирует стандартная "Студийная" библиотека времени выполнения msvcrt.dll. По-видимому, это её работа. А если учесть, что в системе может быть установлена произвольная версия этой библиотеки...
Но это уже тема для отдельного поста. Как всегда пиши комментарии (регистрация не требуется) или на почту acbib3@yandex.ru.
