ГЛАВА 16 Стек потока

Иногда система сама резервирует какие-то регионы в адресном пространстве Ва шего процесса. Я уже упоминал в главе 13, что это делается для размещения блоков переменных окружения процесса и его потоков. Еще один случай резервирования ре гиона самой системой — создание стека потока

Всякий раз, когда в процессе создается поток, система резервирует регион адрес ного пространства для стека потока (у каждого потока свой стек) и передает этому региону какой-то объем физической памяти По умолчанию система резервирует 1 Мб адресного пространства и передает ему всего две страницы памяти. Но стандартные значения можно изменить, указав при сборке программы параметр компоновщика /STACK

/STACK. reserve [, commit]

Тогда при создании стека потока система зарезервирует регион адресного про странства, размер которого указан в параметре /STACK компоновщика Кроме того, объем изначально передаваемой памяти можно переопределить вызовом CreateThread или _beginthreadex. У обеих функций есть параметр, который позволяет изменять объем памяти, изначально передаваемой региону стска Если в нем передать 0, систе ма будет использовать значение, указанное в параметре /STACK Далее я исхожу ич того, что стек создается со стандартными параметрами.

На рис. 16-1 показано, как может выглядеть регион стека (зарезервированный по адресу 0x08000000) в системе с размером страниц no 4 Кб Регион стека и вся пере данная ему память имеют атрибут защиты PAGE_READWRITE.

Зарезервировав регион, система передает физическую память двум верхним его страницам. Непосредственно перед тем, как приступить к выполнению потока, сис тема устанавливает регистр указателя стека на конец верхней страницы региона сте ка (адрес, очень близкий к 0x08100000). Это та страница, с которой поток начнет использовать свой стек Вторая страница сверху называется сторожевой (guard page)

По мере разрастания дерева вызовов (одновременного обращения ко все больше му числу функций) потоку, естественно, требуется и больший объем стека. Как толь ко поток обращается к следующей странице (а она сторожевая), система уведомляет ся об этой попытке. Тогда система передает память еще одной странице, расположен ной как раз за сторожевой. После чего флаг PAGE_GUARD, как эстафетная палочка, переходит от текущей сторожевой к той странице, которой только что передана па мять. Благодаря такому механизму объем памяти, занимаемой стеком, увеличивается только по необходимости. Если дерево вызовов у потока будет расти и дальше, реги он стека будет выглядеть примерно так, как показано на рис. l6-2

Допустим, стек потока практически заполнен (как па рис. l6-2) и регистр указа теля стека указывает на адрес 0x08003004. Тогда, как только поток вызовет еще одну функцию, система, по идее, должна передать дополнительную физическую память. Но

когда система передает! память странице по адресу 0x08001000, она делает это уже по-другому Регион стека теперь выглядит, как на рис l6-3

Рис. 16-1. Так выглядит регион стека потока сразу после его создания

Рис. 16-2. Почти заполненный регион стека потока

Рис. 16-3. Целиком заполненный регион стека потока

Как и можно было предполагать, флаг PAGE_GUARD со страницы по адресу 0x08002000 удаляется, а странице по адресу 0x08001000 передается физическая па мять. Но этой странице не присваивается флаг PAGE_GUARD. Это значит, что региону адресного пространства, зарезервированному под стек потока, теперь передана вся физическая память, которая могла быть ему передана. Самая нижняя страница оста ется зарезервированной, физическая память ей никогда не передается. Чуть позже я поясню, зачем это сделано

Передавая физическую память странице по адресу 0x08001000, система выполня ет еще одну операцию генерирует исключение EXCEPTION_STACK_OVERFLOW (в файле WinNT.h оно определено как 0xC00000FD). При использовании структурной обработки исключений (SEH) Ваша программа получит уведомление об этой ситуа ции и сможет корректно обработать ее. Подробнее о SEH см. главы 23, 24 и 25, а так же листинг программы Summation, приведенный в конце этой главы

Если поток продолжит использовать стек даже после исключения, связанного с переполнением стека, будет задействована вся память на странице по адресу 0x08001000, и поток попытается получить доступ к странице по адресу 0x08000000 Поскольку эта страница лишь зарезервирована (но не передана), возникнет исклю чение — нарушение доступа. Если это произойдет в момент обращения потока к сте ку, Вас ждут крупные неприятности. Система возьмет управление на себя и завершит нс только данный поток, но и весь процесс И даже не сообщит об этом пользовате лю; процесс просто исчезнет!

Теперь объясню, почему нижняя страница стека всегда остается зарезервирован ной Это позволяет защищать другие данные процесса от случайной перезаписи Ви дите ли, по адресу 0x07FFF000 (па 1 страницу ниже, чем 0x08000000) может быть передана физическая память для другого региона адресного пространства. Если бы странице по адресу 0x08000000 была передана физическая память, система не суме

ла бы перехватить попытку потока расширить стек за прелелы зарезервированного региона. А если бы стек расползся за пределы этого региона, поток мог бы перезапи сать другие даипые в адресном пространстве своего процесса — такого *жучка» вы ловить очень сложно.

Стек потока в Windows 98

В Windows 98 стеки ведут себя почти так же, как и в Windows 2000. Но отличия все же есть.

На рис. 16-4 показано, как в Windows 98 может выглядеть регион стека (зарезер вированный с адреса 0x00530000) размером 1 Мб.

Рис. 16-4. Так выглядит регион стека сразу после его создания под управлением Windows 98

Во-первых, размер региона на самом дслс 1 Мб плюс 1 28 Кб, хотя мы хотели соз дать стек объемом всего 1 Мб. В Windows 98 система резервирует под стек на 128 Кб больше, чсм было запрошено. Собственно стек располагается в середине этого реги она, а по обеим его границам размещаются блоки по 64 Кб каждый.

Блок перед стеком предназначен для перехвата его переполнения, а блок после стска — для перехвата обращений к несуществующим областям стека. Чтобы понять, какая польза от последнего блока, рассмотрим такой фрагмент кода:

int WINAPI WinMain(HINSTANCE hinstExe, HINSTANCE, PSTR pszCmdLine, int nGmdShow)
{

char szBuf[100];

szBuf[10000] - 0; // обращение к несуществующей области стека

return(0);

}

Когда выполняется оператор присвоения, происходит попытка обращения за ко нец стека потока. Разумеется, ни компилятор, ни компоновщик не уловят эту ошибку в приведенном фрагменте кода, по, если приложение работает под управлением Win

dows 98, выполнение этого оператора вызовет нарушение доступа. Это одна из при ятных особенностей Windows 98, отсутствующих в Windows 2000, в которой сразу за стеком потока может быть расположен другой регион И если Вы случайно обрати тесь за пределы стека, Вы можете испортить содержимое области памяти, принадле жащей другой части Вашего процесса, — система ничего не заметит.

Второе отличие: в стске нет страниц с флагом атрибутов защиты PAGE_GUARD. Пocкoлькy Windows 98 такой флаг не поддерживает, при расширении стека потока она действует несколько иначе. Она помечает страницу переданной памяти, располагаемой под стеком, атрибутом PAGE_NOACCESS (на рис, 16-4 — по адресу 0х0063Е000). Когда поток обращается к этой странице, происходит нарушение доступа. Система пере хватывает это исключение, меняет атрибут защиты страницы с PAGE_NOACCESS на PAGE_READWRITE и передает память новой "сторожевой" странице, размещаемой сразу за предыдущей.

Третье: обратите внимание на единственную страницу с атрибутом PAGE_READ WRITE по адресу 0x00637000. Она создается для совместимости с 16-разрядной Win dows. Хотя Microsoft нигде нс говорит об этом, разработчики обнаружили, что пер вые 16 байтов cегмента стека 16-разрядной программы содержат информацию о ее стeке, локальной куче и локальной таблице атомарного доступа. Поскольку Win32 приложения в Windows 98 часто обращаются к 16-разрядным DLL и некоторые из этих DLL предполагают наличие тех самых 16 байтов в начале сегмента стека, Microsoft пришлось эмулировать подобные данные и в Windows 98. Когда 32-разрядный код обращается к 16-разрядному, Windows 98 отображает 16-битный селектор процессо ра на 32-разрядный стек и записывает в регистр сегмента стека (SS) такое значение, чтобы он указывал на страницу по адресу 0x00637000. И тогда 16-разрядный код, получив доступ к своим 16 байтам в начале сегмента стека, продолжает выполнение без всяких проблем

По мере роста стека потока, выполняемого под управлением Windows 98, блок памяти по адресу 0x0063F000 постепенно увеличивается, а сторожевая страница сме щается вниз до тех пор, пока не будет достигнут предел в 1 Мб, после чего она исче зает так же, как и в Windows 2000. Одновременно система смещает позицию страни цы, предназначенной для совместимости с компонентами 16-разрядной Windows, и она, в конце концов, попадает в 64-килобайтовый блок, расположенный в начале ре гиона стека. Поэтому целиком заполненный стек в Windows 98 выглядит так, как по казано на рис. 16-5.

Рис. 16-5. Целиком заполненный регион стека потока в Windows 98

Функция из библиотеки С/С++ для контроля стека

Библиотека С/С++ содержит функцию, позволяющую контролировать стек. Трансли руя исходный код программы, компилятор при необходимости генерирует вызовы этой функции. Она обеспечивает корректную передячу страниц физической памяти стеку потока.

Возьмем, к примеру, небольшую функцию, требующую массу памяти под свои локальные переменные:

void SomeFunction()
{

int nValues[4000];

// здесь что-то делаем с массивом

nValuesjOj = 0; // а тут что-то присваиваем

}

Для размещения целочисленного массива функция потребует минимум 16 000 байтов стекового пространства, так как каждое целое значение занимает 4 байта. Код, генерируемый компилятором, обычно выделяеттакое пространство в стеке простым уменьшением указателя стека процессора на 16 000 байтов. Однако система не пере даст физическую память этой нижней области стека, пока не произойдет обращения по данному адресу

В системе с размерим страниц по 4 или 8 Кб это могло бы создать проблему. Если первое обращение к стеку проходит по адресу, расположенному ниже сторожевой страницы (как в показанном выше фрагменте кода), поток обратится к зарезервиро ванной памяти, и возникнет нарушение доступа. Поэтому, чтобы можно было спокой но писать функции вроде приведенной выше, компилятор и вставляет в код вызовы библиотечной функции для контроля стека.

При трансляции программы компилятору известен размер страниц памяти, ис пользуемых целевым процессором (4 Кб для x86 и 8 Кб для Alpha). Встречая в про грамме ту или иную функцию, компилятор определяет требуемый для нее объем сте ка и, если он превышает размер одной страницы, вставляет вызов функции, контро лирующей стек.

Нижс показан псевдокод, который иллюстрирует, что именно делает функция, контролирующая стек. (Я говорю «псевдокод» потому, что обычно эта функция реа лизуется поставщиками компиляторов на языке ассемблера.)

// стандартной библиотеке С "известен" размер страницы в целевой системе

#ifdef _M_ALPHA

#define PAGESIZE (8 * 1024) // страницы по 8 Кб

#else

#define PAGESIZE (4 * 1024) // страницы по 4 Кб

#endif

void StackCheck(int nBytesNeededFromStack)
{

// Получим значение указателя стека. В этом месте указатель стека
// еще НЕ был уменьшен для учета локальных переменных функции.
PBYTE pbStackPfr = (указатель стека процессора);

while (nBytesNeededFromStack >= PAGESIZE)
{

// смещаем страницу вниз по стеку - должна быть сторожевой
pbStackPtr -= PAGESIZE;

// обращаемся к какому-нибудь байту на сторожевой странице, вызывая
// тем самым передачу новой страницы и сдвиг сторожевой страницы вниз
pbSTackPtr[0] = 0;

// уменьшаем требуемое количество байтов в стеке
nBytesNeededFromStack -= PAGESIZE;

}

// перед возвратом управления функция StackCheck устанавливает регистр
// указателя стека на адрес, следующий за локальными переменными функции

}

В компиляторе Microsoft Visual C++ предусмотрен параметр, позволяющий конт ролировать пороговый предел числа страниц, начиная с которого компилятор авто матически вставляет в программу вызов функции StackCheck. Используйте этот пара метр, только если Вы точно знаете, что делаете, и если это действительно нужно. В 99,99999 процентах из ста приложения и DLL не требуют применения упомянутого параметра.

Программа-пример Summation

Эта программа, "16 Summation.exe" (см. листинг на рис. 16-6), демонстрирует исполь зование фильтров и обработчиков исключений для корректного восстановления пос ле переполнения стека. Файлы исходного кода и ресурсов этой программы находят ся в каталоге l6-Summation на компакт-диске, прилагаемом к книге. Возможно, Вам придется сначала прочесть главы по SEH, чтобы понять, как работает эта программа. Она суммирует числа от 0 до x, где x — число, введенное пользователем. Конечно, проще было бы написать функцию с именем Sum, которая вычисляла бы по формуле:

Sum = (x * (x + 1)) / 2;

Но для этого примера я сделал функцию Sum рекурсивной, чтобы она использо вала большое стековое пространство.

При запуске программы появляется диалоговое окно, показанное ниже.

В этом окне Вы вводите число и щелкаете кнопку Calculate. Программа создает поток, единственная обязанность которого - сложить все числа от 0 до x. Пока он выполняется, первичный поток программы, вызвав WaitForSingleOhject, просит систе му не выделять ему процессорное время. Когда новый поток завершается, система вновь выделяет процессорное время первичному потоку. Тот выясняет сумму, полу чая код завершения нового потока вызовом GetExitCodeThread, и — это очень важно — закрывает свой описатель нового потока, так что система может уничтожить объект ядра "поток", и утечки ресурсов не произойдет.

Далее первичный поток проверяет код завершения суммирующего потока. Если он равен UINT_MAX, значит, произошла ошибка: суммирующий поток переполнил стек при подсчете суммы; тогда первичный поток выведет окно с соответствующим сообщением. Если же код завершения отличен от UINT_MAX, суммирующий поток

отработал успешно; код завершения и есть искомая сумма. Б этом случае первичный поток просто отображает результат суммирования в диалоговом окне.

Теперь обратимся к суммирующему потоку, Его функция — SumThreadFunc, При создании этого потока первичный поток передает ему в единственном параметре pvParam количество целых чисел, которые следует просуммировать. Затем его функ ция инициализирует переменную uSum значением UINT_MAX, т. e. изначально пред полагается, что работа функции не завершится успехом Далсс SumThreadFunc акти визирует SEH так, чтобы перехватывать любое исключение, возникающее при вы полнении потока. После чего для вычисления суммы вызывается рекурсивная функ ция Sum.

Если сумма успешно вычислена, SumThreadFunc просто возвращает значение пе ременной uSum, оно и будет кодом завершения потока. Но, если при выполнении Sum возникает исключение, система сразу оценивает выражение в фильтре исключений. Иначе говоря, система вызывает FilterFunc, передавая ей код исключения. R случае переполнения стека этим кодом будет EXCEPTION_STACK_OVERFLOW. Чтобы увидеть, как программа обрабатывает исключение, вызванное переполнением стека, дайте ей просуммировать числа от 0 до 44000.

Моя функция FilterFunc очень проста. Сначала она проверяет, произошло ли ис ключение, связанное с переполнением стека. Если нет, возвращает EXCEPTION_CON TINUE_SEARCH, а если да — EXCEPTION_EXECUTE_HANDLER Это подсказывает сис теме, что фильтр готов к обработке этого исключения и что надо выполнить код в блоке except. В данном случае обработчик исключения ничего особенного не делает, просто закрывая поток с кодом завершения UINT_MAX Родительский поток, получив это специальное значение, выводит пользователю сообщение с предупреждением.

И последнее, что хотелось бы обсудить; почему я выделил функцию Sum в отдель ный поток вместо того, чтобы просто создать SEH-фрейм в первичном потоке и вы зывать Sum из его блока try. На то есть три причины.

Во-первых, всякий раз, когда создается поток, он получает стек размером 1 Мб. Если бы я вызывал Sum из первичного потока, часть стекового пространства уже была бы занята, и функция не смогла бы использовать весь объем стека. Согласен, моя про грамма очень проста и, может быть, не займет слишком большое стековое простран ство. А если программа посложнее? Легко представить ситуацию, когда Sum подсчи тывает сумму целых чисел от 0 до 1000 и стек вдруг оказывается чем-то занят, — тог да его переполнение произойдет, скажем, еще при вычислении суммы от 0 до 750. Таким образом, работа функции Sum будет надежнее, если предоставить ей полный стек, не используемый другим кодом.

Вторая причина в том, что поток уведомляется об исключении «переполнение стека» лишь однажды Если бы я вызывал Sum из первичного потока и произошло бы переполнение стека, то это исключение было бы перехвачено и корректно обрабо тано. Но к тому моменту физическая память была бы передана под все зарезервиро ванное адресное пространство стека, и в нем уже не осталось бы страниц с флагом защиты. Начни пользователь новое суммирование, и функция Sum переполнила бы стек, а соответствующее исключение не было бы возбуждено, Вместо этого возникло бы исключение «нарушение доступа", и корректно обработать эту ситуацию уже не удалось бы.

И последнее, почему я использую отдельный поток: физическую память, отведен ную под его стек, можно освободить. Рассмотрим такой сценарий: пользователь про сит функцию Sum вычислить сумму целых чисел от 0 до 30 000. Это требует передачи региону стека весьма ощутимого объема памяти. Затем пользователь проводит не

сколько операций суммирования — максимум до 5000 И окажется, что стеку передан порядочный объем памяти, который больше не используется А ведь эта физическая память выделяется из страничною файла Так что лучше бы освободить се и вернуть системе И поскольку программа завершает поток SumThreadFunc, система автомати чески освобождает физическую память, переданную региону стека

Summation