Выпуск новостей ReactOS №67

Z98, “ReactOS Newsletter 67”, public translation into Russian from English More about this translation.

See also 88 similar translations

Translate into another language.

Participants

evilslon1 1034 points
mister-fog 137 points
jedi-to-be 33 points
And others...
Join Translated.by to translate! If you already have a Translated.by account, please sign in.
If you do not want to register an account, you can sign in with OpenID.
Pages: ← previous Ctrl next
1 2 3

ReactOS Newsletter 67

Выпуск новостей ReactOS №67

History of edits (Latest: mister-fog 7 years, 11 months ago) §

Debugging

Отладка

History of edits (Latest: evilslon1 7 years, 11 months ago) §

The last time WinDBG support was discussed up was nearly a year ago. The first step needed was a kernel compatible with WinDBG, which was achieved by the kernel rewrite that mostly concluded two years ago. The required features mostly revolved around dealing with an executing thread's context and reading virtual memory. While the kernel rewrite made these possible, a few bugs prevented their usage. Debugging requires interrupting the executing thread's flow but also restoring it to allow the program to continue. One such bug actually corrupted the execution context and ultimately crashed whatever was being debugged as a result. Another such problem was the HAL attempting to map the first physical page using the memory manager. This failed as the function in the memory manager did some additional synchronization, none of which would work if the HAL was running in a debugging context after a reboot. When running in such a debugging context, none of the synchronization being performed was needed, and there was a risk that the locks in question were already held by something else. This could result in a deadlock and freeze the system. With these and other fixes, Stefan managed to connect to the ReactOS kernel with WinDBG and perform actions such as setting and clearing breakpoints and reading I/O and memory. However, connecting to ReactOS required using the Windows 2003 KDCOM driver.

С тех пор, как мы последний раз обсуждали поддержку WinDBG прошел почти год. На первом этапе нам было необходимо переписать часть кода ядра, чтобы добиться его совместимости с WinDBG. Основная часть требуемого функционала была связана с контекстом выполняющего потока и чтением виртуальной памяти. И хотя эти функции были реализованы два года назад, несколько ошибок не позволяли их использовать. Отладка требует не только прерывание выполняющегося потока нити, но и его восстановление для продолжения работы программы. Одна из ошибок повреждала контекст выполнения, и в конечном счете, разрушала все, что отлаживалось. Другой проблемой был HAL, пытающийся использовать первую физическую страницу при помощи диспетчера памяти, что невозможно, поскольку функция в диспетчере памяти выполняла дополнительную синхронизацию, которая работала бы некорректно, если бы HAL находился в контексте отладки после перезагрузки. Работая в этом контексте, ни одна из выполняемых синхронизаций не была необходима, а кроме того, был риск, что рассматриваемые блокировки были уже проведены чем-либо ещё. Это могло привести к взаимной блокировке и зависанию системы. Исправив эти и другие ошибки, Штефану удалось заставить взаимодействовать ядро ReactOS и WinDBG, что позволило выполнить такие действия, как установка и очистка контрольных точек, чтение ввода-вывода и памяти. Однако, это взаимодействие в ReactOS осуществляется лишь при использовании драйвера KDCOM из операционной системы Windows 2003.

History of edits (Latest: mister-fog 7 years, 11 months ago) §

The reason Stefan used the Windows 2003 KDCOM driver was because the ReactOS KDCOM simply did not work correctly at the time Stefan began his work. Despite Timo Kreuzer's efforts to make it compatible, it had not reached a point where he could rely on it and not have to figure out where the point of failure was between KDCOM and the kernel. At about the same time Stefan took an interest in WinDBG support, Timo resumed his work on the ReactOS KDCOM on the x64 branch. A variety of timing issues caused missing characters and dropped packets, especially for larger ones, and made the driver rather unreliable. Timo added additional error checking and handling to compensate for this. One odd timing issue was attempts to write out to the serial port would fail with the device claiming it was not ready to send, even though checking its status returned ready. Timo's current fix simply builds in a delay which seems to give the serial port enough time to actually accept data, but this solution is less than ideal. Timo's current test platform is Virtual Box, which has a history of problematic serial output. Just getting regular debug output from ReactOS using Virtual Box took testers some time to figure out and even after that the formatting of the messages ended up completely jumbled at times. The Virtual Box project seems to be planning a rewrite of their serial implementation, which will hopefully resolve the problems our project has experienced and allow for more reliable testing of KDCOM and WinDBG.

Причина, по которой Штефан использовал драйвер KDCOM из Windows 2003, была в том, что KDCOM ReactOS попросту некорректно работал, когда Штефан начал свои работы. Несмотря на все усилия Тимо Кройцера (Timo Kreuzer) сделать его совместимым, драйвер так и не достиг того уровня, когда на него можно было положиться и не было бы больше необходимости догадываться, где между KDCOM и ядром произошел отказ. Приблизительно в то же самое время, когда Штефан проявил интерес к поддержке WinDBG, Тимо возобновил свою работу над драйвером KDCOM ReactOS для ветки x64. Множественные проблемы синхронизации приводили к потере символов и пропуску пакетов, в особенности больших, и сделали драйвер довольно ненадежным. Тимо добавил дополнительную проверку ошибок и поддержку их компенсации. Странной проблемой синхронизации, к примеру, являлось то, что попытки записи в последовательный порт невозможно, так как устройство выдает информацию о неготовности к передаче, хотя результаты проверки состояния порта свидетельствуют о его готовности. Текущая доработка Тимо просто устанавливает задержку, которая, как кажется, дает последовательному порту достаточно времени, чтобы обеспечить приём данных, но это решение далеко не идеально. На настоящий момент испытательной платформой Тимо является VirtualBox, который ведёт хронологию проблем вывода в последовательный порт. Только выяснение того, как организовать регулярный сбор отладочной информации из ReactOS используя VirtualBox потребовало у тестеров некоторое время, и, даже после этого, результаты форматирования сообщений оказались полностью перемешаны во времени. Похоже, что проект VirtualBox планирует переписать реализацию последовательного порта, это, как мы надеемся, решит проблемы, которые испытал наш проект и позволит провести более надежное тестирование KDCOM и WinDBG.

History of edits (Latest: mister-fog 7 years, 11 months ago) §
Pages: ← previous Ctrl next
1 2 3