Функция из библиотеки С/С++ для контроля стека
Библиотека С/С++ содержит функцию, позволяющую контролировать стек. Трансли руя исходный код программы, компилятор при необходимости генерирует вызовы этой функции. Она обеспечивает корректную передячу страниц физической памяти стеку потока.
Возьмем, к примеру, небольшую функцию, требующую массу памяти под свои локальные переменные:
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, система автомати чески освобождает физическую память, переданную региону стека
В Windows 98 стеки ведут
В Windows 98 стеки ведут себя почти так же, как и в Windows 2000. Но отличия все же есть.
На рис. 16-4 показано, как в Windows 98 может выглядеть регион стека (зарезер вированный с адреса 0x00530000) размером 1 Мб.
| Адрес | Размер | Состояние страницы |
| 0x00640000 | 16 страниц (65 536 байтов) | Верхняя часть стека (зарезервирована для перехвата обращений к несуществующей области стека) |
| 0x0063F000 | 1 страница (4096 байтов) | Переданная страница с атрибутом PAGE_READWRITE (задействованная область стека) |
| 0x0063E000 | 1 страница (4096 байтов) | Страница с атрибутом PAGE_NOACCESS (заменяет флаг PAGE_GUARD) |
| 0x00638000 | 6 страниц (24 576 байтов) | Страницы, зарезервированные для перехвата переполнения стека |
| 0x00637000 | 1 страница (4096 байтов) | Переданная страница с атрибутом PAGE_READWRITE (для совместимости с 16-разрядными компонентами) |
| 0x00540000 | 247 страниц (1 011 712 байтов) | Страницы, зарезервированные для дальнейшего расширения стека |
| 0x00530000 | 16 страниц (65 536 байтов) | Нижняя часть стека {зарезервирована для перехвата переполнения стека) |
Во-первых, размер региона на самом дслс 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.
| Адрес | Размер | Состояние страницы |
| 0X00640000 | 16 страниц (65 536 байтов) | Верхняя часть стека (зарезервирована для перехвата обращений к несуществующей области стека) |
| 0X00540000 | 256 страниц (1 Мб) | Переданная страница с атрибутом PAGE_READWRITE (задействованная область стека) |
| 0x00539000 | 7 страниц (28 672 байта) | Страницы, зарезервированные для перехвата переполнения стека |
| 0X00538000 | 1 страница (4096 байтов) | Переданная страница с атрибутом PAGE_READWRITE (для совместимости с 16-разрядными компонентами) |
| 0x00530000 | 8 страниц (32 768 байтов) | Нижняя часть стека (зарезервирована для перехвата переполнения стека) |
