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

Z98, “ReactOS Newsletter - Newsletter 58 (#58)”, public translation into Russian from English More about this translation.

See also 86 similar translations

Translate into another language.

Participants

bz00mmer 590 points
seven_ro 513 points
aspotashev 133 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

Aleksey also opined for a heap debugger, but that might prove tricky considering heap allocations are far more frequent.

Алексей также думал об отладчике для кучи (куча - структура данных, используемая для динамического выделения памяти в приложениях), но это может оказаться сложнее, так как выделения памяти из кучи выполняются гораздо чаще.

History of edits (Latest: seven_ro 8 years, 7 months ago) §

— об отладчике кучи - нужно как-то подругому, не совсем понятно для народа seven_ro

— Слово "куча" смущает? http://ru.wikipedia.org/wiki/Куча_(не...bz00mmer

As an aside, Aleksey also fixed an issue in USB that was causing crashes on real hardware. The USB code was trying to remove a pointer from a nonexistent linked list, which ended up corrupting the pool. This would be an example of an underwrite error that the pool debugger does not yet detect.

Кроме того, Алексей исправил проблему с драйвером USB, которая была причиной сбоя при работе с физическими устройствами. Код драйвера USB пытался удалить указатель из несуществующего связанного списка, что в конечном итоге портило пул. Этот случай является одним из примеров ошибочной перезаписи, которую отладчик пула ещё не способен обнаруживать.

History of edits (Latest: apodavalov 8 years, 6 months ago) §

More Memory

И ещё про память

History of edits (Latest: bz00mmer 8 years, 7 months ago) §

In the process of fixing a bug exposed by OllyDbg, Michael Martin also accidentally fixed installation of Mono. The exact reasons why OllyDbg and Mono both choked on this bug is still unclear, but Michael is fairly certain it is fixed. Effectively what happened was that OllyDbg called a series of functions, starting with CreateFileMappingA. The point of interest is in the size that is used to decide how much memory to allocate for the creation. OllyDbg then called MapViewOfFile, and here's where things can go wrong. The MapViewOfFile function and those it calls looked for a SEC_IMAGE data structure that might or might not have been defined by CreateFileMapping and the functions it called. If it found the data structure, it would take the size specified in it and round it so it was page size aligned. If it could not find SEC_IMAGE, the function would pull the size from a FileObject data structure created by the CreateFileMapping call chain. This value however was not rounded up. This caused problems when OllyDbg called the third function in this sequence, VirtualQuery. This function ultimately information about an area of memory, including the size. OllyDbg apparently expected the size to be page aligned and did not take receiving a non-aligned size well.

В процессе исправления ошибки, порождаемой программой OllyDbg, Майкл Мартин (Michael Martin) также неумышленно исправил процесс установки программы Mono. Истинная причина, по которой OllyDbg и Mono завершались с ошибкой до этого исправления, остаётся неясной, однако Майкл, очевидно, решил саму проблему. Что же именно происходит, когда OllyDbg вызывает несколько функций, начиная с CreateFileMappingA? Интерес для нас представляет определение объёма требуемой памяти. Далее OllyDbg вызывает функцию MapViewOfFile и здесь всё сбивается с пути. Функция MapViewOfFile (и вызывающий её код) смотрят на структуру данных SEC_IMAGE, которая может быть, а может не быть создана при вызове функции CreateFileMapping (и в коде, вызывающем её). Если структуру удаётся обнаружить, то будет использован указанный в ней размер, округлённый до границы страницы. Если же структура SEC_IMAGE не найдена, функция MapViewOfFile должна получить размер из структуры FileObject, созданной ранее в функции CreateFileMapping. Однако здесь это значение не округлялось. Это и порождало проблемы, когда OllyDbg вызывал третью функцию из этой последовательности, VirtualQuery. Эта функция уже обладает информацией об области памяти, включая её размер. OllyDbg, очевидно, ожидает, что размер будет округлен до границы страницы и не способен работать с неокругленным размером.

History of edits (Latest: apodavalov 8 years, 6 months ago) §

— OllyDbg как я понимаю это программа для отладки? seven_ro

— Да, отладчик приложений пользовательского режима bz00mmer

Сломал голову, переводя :) bz00mmer

Michael originally did not realize that the rounding wasn't taking place and did some testing on Windows XP. There he noticed that VirtualQuery was always returning a page aligned size, so he backtracked in ReactOS to see where this alignment was not happening and found the bug. Exactly how this was messing with Mono no one is entirely sure, as no one had actually bothered to see what was causing Mono to fail in the first place. All the testers are sure of is that after Martin committed this fix, they were able to successfully install Mono.

Майкл изначально не понимал, что округления не происходит, и провёл некоторые исследования в Windows XP. Там он обнаружил, что VirtualQuery всегда возвращает размер, кратный размеру страницы, так что он вернулся в ReactOS, чтобы увидеть, где этого округления не происходит, и обнаружил ошибку. По какой именно причине начала работать программа установки для Mono, никто не мог сказать с уверенностью, так как ещё никто не разбирался, по какой причине в ней происходил этот сбой. Однако, все тестеры уверены в том, что после того как Мартин внёс данное исправление, у них появилась возможность успешно установить Mono.

History of edits (Latest: apodavalov 8 years, 6 months ago) §

Comment was deleted

— "уверены, что это так", "уверены в том, что", я думаю bz00mmer

Pages: previous Ctrl next →
1 2