ReactOS Newsletter - Newsletter 58 (#58)

Author: Z98. Link to original: http://www.reactos.org/ru/newsletter_58.html (English).
Tags: ReactOS Submitted by apodavalov 17.05.2009. Public material.

Translations of this material:

into Russian: Выпуск новостей ReactOS №58. Translation complete.
Submitted for translation by apodavalov 17.05.2009 Published 8 years, 2 months ago.

Text

UniATA

The Universal ATA driver has often been pointed out as a way to solve some rather annoying issues in ReactOS, such as the lack of support for SATA and limiting the amount of space ROS sees to about 8GB. Since both issues border on the outright absurd in this day and age, fixing them was of very high priority. A few showstoppers stood in the way however of switching over permanently and Aleksey Bragin has managed to resolve some of them. The biggest issue involved UniATA not detecting CD-ROMs on real hardware, which Aleksey tracked down to be because of timing issues. The developer of UniATA had decided to lower the waiting time for several operations, which could result in controllers not having enough time to change their states. Aleksey changed the wait times to match that found in the old atapi driver and now drives are detected reliably on real hardware.

Another issue that has not been fixed yet is UniATA failing on VirtualBox. The cause is still unknown, but is next on Aleksey's list.

Pool

As part of the effort to see where corruption is occuring, Aleksey has also been double checking usage of the memory pool. The pool is essentially a way for the kernel and drivers to allocate memory, and it can be both paged (written out to disk) and nonpaged (always in memory). Aleksey has been working on a new implementation and as part of that wrote what is essentially a pool debugger, able to check for overflows in either reading or writing to allocated pools. Running it, he only discovered one over-read in the PnP manager. The tool doesn't check for under reads or writes, so those could still be floating around. At least in the future, the team will have a tool to make sure no further such mistakes are made. All this is in preparation for a new pool implementation that Aleksey has been working but could not commit as something that ReactOS does causes crashes when the new code is used. Hopefully with the debugger Aleksey can track down what the cause is.

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

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.

More Memory

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.

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.