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

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

See also 103 similar translations

Translate into another language.

Participants

evilslon 767 points
jedi-to-be 600 points
Farwalker 35 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

ReactOS Newsletter: Newsletter 76

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

History of edits (Latest: alexgearbox 7 years, 3 months ago) §

Hunting Dangling Pointers

Охота на призраков

History of edits (Latest: jedi-to-be 7 years, 3 months ago) §

There has always been a suspicion and concern amongst the ReactOS developers that there are points of sloppiness in ReactOS with respect to memory management. These can be fairly innocuous when at the user mode level, but in kernel mode can lead to data corruption and other problems. Cameron Gutman, Timo Kreuzer, and Michael Martin have just managed to find and fix what was perhaps the most serious of these suspected leaks. Michael had encountered the issue when running ROS in his customized version of QEMU but could not find the exact line of the corruption. Timo eventually found the line in question during his own investigations and Cameron helped verify the cause and test possible fixes.

Управление памятью в ReactOS всегда вызывало сомнения и недоверие у разработчиков ReactOS, поскольку в коде диспетчера памяти таится неопределённое количество скрытых ошибок. Они могут быть относительно безопасны при работе программ в пользовательском режиме, где возникновение критической ошибки практически невозможно. Однако, при работе программы в режиме ядра, эти же ошибки приводят к краху системы. Кэмерону Гутману (Cameron Gutman), Тимо Кройцеру (Timo Kreuzer) и Михаэлю Мартину (Michael Martin) удалось обнаружить причину нескольких из, пожалуй, наиболее серьезных утечек памяти. Михаэль столкнулся с проблемой при работе ROS на его модифицированной для отладки версии QEMU, но не мог найти строку кода, вызывающую повреждение памяти. В ходе исследований, Тимо нашёл код, который мог бы вызвать подобную ошибку, а Кэмерон помог проверить причину и протестировать исправляющий её патч.

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

— ПопячьсЯ =)  jedi-to-be

— "точки небрежности" - это тоже с уепячки термин?  evilslon

More 8 comments

— Согласен на все 100%, только чуть поправлю предложение evilslon

The problem relates to how memory for individual processes are managed. In most modern operating systems, each process has what is known as a virtual address space. These spaces fill the entire range of a platform's native size, so 32 bits effectively gives one 4GB of memory addresses. There's considerably more to virtual memory management than that, but the simplified explanation will suffice. These address spaces essentially allow a process to not have to worry about the memory usage of other processes, at least on a naive level. That complexity is left to the operating system and the hardware running everything. However, the OS does need to do some bookkeeping and maintains a doubly linked list of processes for this purpose. Linked lists basically hold not only the data one wants them to but also a reference to the next item in the list. Doubly linked lists hold a reference both to the next item and the preceding one.

Обнаруженная ими проблема находилась в механизме управления памятью, выделяемой для отдельных процессов. В большинстве современных операционных систем каждый процесс имеет так называемое виртуальное адресное пространство. Эти пространства заполняют весь диапазон адресов платформы, поэтому 32-битная платформа предоставляет возможность адресовать 4 Гб оперативной памяти. При этом, конечно, по большей части происходит управление виртуальной памятью, а не физической, однако и такого упрощённого объяснения будет вполне достаточно. Наличие таких адресных пространств позволяет процессам не беспокоиться об использовании памяти других процессов, по крайней мере, так должно быть. Всю сложную работу берёт на себя операционная система и аппаратное обеспечение компьютера. Поэтому, для обеспечения правильного доступа процессов к памяти, операционной системе необходимо вести учёт ресурсов и поддерживать дважды связанный список процессов. Связанные списки, в основном, содержат не только необходимые данные, но и ссылки на следующий элемент в списке. Дважды связанные списки же содержат ссылку и на следующий, и на предыдущий элементы.

History of edits (Latest: evilslon 7 years, 3 months ago) §

Because the list of processes is rather important to the OS, it was kept in non-paged pool, or kernel mode memory that is never paged out to disk and always in memory. Since non-paged pool is a rather valuable and often very limited resource to the OS, it must be used carefully. However, there was a bug in the code that did not remove entries from the list when processes were terminated. This by itself would not have resulted in data corruptions, except the data in the lists were being freed. Thus the area in memory being pointed to was no longer valid and could have been assigned to something else. Even then the issue might have not affected the system activity, except that whenever a new process is created, a new entry must be added onto the list. This required modification of the now invalid entry, as its next value must be set to the new entry. However, if that area of memory was being used by something else, then its data would be modified and effectively corrupted. Since non-paged pool is generally used for fairly critical pieces of data needed to keep everything running, any corruption to it becomes a very bad thing. The fix for this is quite simply to remove the invalid entries, but the lack of the fix has been causing all sorts of headaches for developers and testers.

Поскольку список процессов крайне важен для механизма управляения памятью операционной системы, он хранился в невыгружаемом пуле памяти (памяти режима ядра), который никогда не выгружается на жёсткий диск и всегда остаётся доступным в памяти. Так как невыгружаемый пул является крайне ценным и зачастую весьма ограниченным ресурсом операционной системы, он должен использоваться настолько экономно, насколько это вообще возможно. В коде ReactOS находилась ошибка, из-за которой при завершении процессов из списка не удалялись соответствующие им записи. Само по себе это не могло привести к повреждению данных даже в том случае, если бы данные в списках были удалены. Таким образом, эта область памяти расценивалась системой как не используемая и доступная для повторного использования. Но даже в этом случае проблема повлияет на работу системы только при создании нового процесса, так как в список должна быть добавлена новая запись. Это потребует изменения уже существующей, повреждённой записи, так как в неё необходимо добавить ссылку на создаваемую запись. Однако, если эта область памяти используется каким-либо другим процессом, то его данные будут изменены и повреждены. Так как невыгружаемый пул обычно используется для действительно критических частей данных, необходимых для обеспечения работоспособности системы, любое его повреждение приводит к крайне печальным результатам. Решение этой проблемы оказалось очень простым, достаточно было просто удалить недействительные записи, но именно отсутствие исправления для этой проблемы и становилось источником головной боли у разработчиков и тестеров.

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