Жизнь и восстановление после StackOverflow

Распространено мнение, что StackOverlow - это приговор. Все, что остается приложению - это красиво схлопнуться, не оставив возможности пользователю продолжить работу, сохранить важные данные, и даже информацию об ошибке.

Дальше я расскажу, зачем и как можно обрабатывать ошибку переполнения стека, а так же какую "свинью" подложила EurekaLog - инструмент, который должен был обеспечивать нас информацией о том, почему клиент снова в бешенстве.

Сначала немного справочной информации о том, как устроен стек.

Устройство стека 

В каждом потоке под стек  резервируется по умолчанию 1 МБ адресного пространства. Зарезервированная память физически еще не выделена. Все адресное пространство разбито на страницы - минимальные блоки, которыми оперирует системный менеджер памяти. Стек растет от большего адреса к меньшему постранично. Память выделяется (становится commited) в момент роста стека. Для того, что бы определить необходимость выделения еще одной страницы из зарезервированных, используется защищенная страница памяти. Это такая страница, которая уже выделена (закомичена)  и помечена флагом Page_Guard. Защищенная страница всегда располагается следом за страницей, в которой находится текущая вершина стека. При росте стека происходит обращение к защищенной странице, система реагирует, снимается флаг Page_Guard со страницы и возбуждается исключение доступа к защищенной странице.  Обработав исключение система понимает, что необходимо выделить еще страницу памяти из зарезервированного пространства и пометить ее флагом Page_Guard. Уже выделенная память стека обратно не возвращается, и страницы остаются commited даже после полной раскрутки стека.
Последняя (в сторону роста стека) зарезервированная страница адресного пространства никогда не выделяется. Она служит буфером, что бы вершина стека не вышла за границы сегмента.

Механизм возбуждения StackOverflow 

В какой-то момент в процессе роста стека остается только одна защищенная страница перед последней зарезервированной. Приложение пытается нарастить стек. С защищенной страницы снимается флаг защиты и происходит попытка выделить еще одну защищенную страницу. Система не разрешает и возбуждает исключение переполнения стека (StackOverflow). Как правило, после этого у нас остается еще почти целая страница для обработки исключения.
С этого времени система снимает с себя ответственность за контроль стека. Page_Guard  в дальнейшем больше не выставляется страницам, и если стек снова достигнет предела, произойдет обращение к последней зарезервированной странице. В результате система убъет поток и приложение. Для пользователя - приложение просто схлопнется.

Почему StackOverflow это проблема

Почему же, зачастую пользователь не видит даже сообщения о переполнении стека? Вместо этого приложение просто исчезает. Все дело в том, что оставшиеся 4 килобайта памяти для обработки исключения это очень мало. В rtl много подобных мест:

procedure FmtStr(var Result: string; const Format: string;
  const Args: array of const; const FormatSettings: TFormatSettings);
var
  Len, BufLen: Integer;
  Buffer: array[0..4095] of Char;
begin
..
end;

Лишь один такой вызов израсходует всю оставшуюся доступную память для того, что бы расположить на стеке массив Buffer. 

В рабочем проекте мы используем EurekaLog для сбора информации о стеке исключений и формирования отчета об ошибке. Но при обработке исключения StackOverflow, эврика обращалась к методам rtl, которые не оставляли нам шанса узнать причину, почему у клиентов на проекте наш продукт в момент работы схлопывается.

Была еще одна причина, которая побудила решить эту проблему кардинально. Большую часть нашего продукта занимает скриптовый движок для исполнения паскаль скриптов. Клиентская логика пишется на паскаль скрипте. Паскаль скрипт динамически подгружается. Таким образом, если программист допустит ошибку при написание скрипта и получит StackOverflow, то не останется другого варианта как снова перезапустить развесистый фреймворк.

Обработка StackOverflow

В MSDN есть функция

  BOOL WINAPI SetThreadStackGuarantee(_Inout_  PULONG StackSizeInBytes);

с помощью которой можно установить размер памяти, который останется доступным после возбуждение StackOverflow для обработки исключения. Функция выполняет простую вещь. Если с помощью ее установить гарантированный размер 8 килобайт, то в этом случае система будет держать перед вершиной стека 2 защищенные страницы по 4 килобайта.  

Теперь мы можем гарантированно собрать информацию об ошибке. Эвристическим путем было выяснено, что для эврики надо 32 кБ. Для перестраховки мы задаем 64кб. Однако следующее переполнение стека будет фатальным. 

Но для полного восстановления после StackOverflow необходимо вернуть защищенные страницы. Когда это сделать? Когда стек свернется, и вершина стека уйдет со страниц, на которых мы хотим восстановить Page_Guard. При этом остается вероятность, что при обработке исключения переполнения стека, мы получим новое переполнение стека. Для этого сразу же после первого переполнения стека выставим на одной верхней странице флаг Page_Guard.  И в случае нового переполнения стека при обработке предыдущего, мы сможем хотя бы сообщить о переполнение стека при обработке переполнения стека и закрыть приложение.

Вот так это выглядит в теории:

На практике будут следующие шаги:

1. Установить гарантированный размер для обработки стека равный 68 кБ;
2. Необходимо повесить хук на возникновение исключения. В случае StackOverflow начать процесс восстановления. Установить на 1 страницу Page_Guard. В Delphi можно повесить для этих целей обработчик на System.ExceptObjProc;
3. Дождаться раскрутки стека. Это самый интересный момент. Тут возможны разные варианты. Один из самых простых вариантов -  установка хука на оконные сообщения и на onIdle. В VCL приложение стек как правило всегда раскручивается до Application.ProcessMessage. Вот тут и попытаемся восстановить остальные 16 защищенных страниц;
4. Если в момент восстановления стека, система возбудила новое исключение StackOverflow, то ничего не остается, как сделать хорошую мину: информируем пользователя об исключении и выполняем перезапуск приложения.

Приведу простейший пример восстановления после StackOverflow. Все начинается с Button1Click и секция initialization:

unit main;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes,
  Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    procedure DoOnMessage(var Msg: TMsg; var Handled: Boolean);
  end;

  function SetThreadStackGuarantee(var StackSizeInBytes:
     Cardinal): LongBool; stdcall; external 'kernel32.dll' name 'SetThreadStackGuarantee';
type
  proc = procedure();
  TRaiseExceptionProc = procedure(ExceptionCode, ExceptionFlags: LongWord;
     NumberOfArguments: LongWord; Args: Pointer); stdcall;
  TExceptObjProc = function(P: PExceptionRecord): Pointer;
var
  Form1: TForm1;
  oldRaiseExceptionProc: TExceptObjProc = nil;
  restoringAfterStackOverlow: boolean = false;
  stackGuaranteeSize: Cardinal;
const
  PageSize = 4096;

function _RaiseExeceptionProc(P: PExceptionRecord): Pointer{Exception};
implementation

{$R *.dfm}

{$POINTERMATH ON}

function GetSegmentStackTop: Pointer; assembler;
type
  NT_TIB32 = packed record
    ExceptionList: DWORD;
    StackBase: DWORD;
    StackLimit: DWORD;
    SubSystemTib: DWORD;
    case Integer of
      0 : (
        FiberData: DWORD;
        ArbitraryUserPointer: DWORD;
        Self: DWORD;
      );
      1 : (
        Version: DWORD;
      );
  end;
asm
  MOV     EAX, FS:[0].NT_TIB32.StackLimit
end;

function GetESP: Pointer; assembler;
asm
   mov result, esp
end;

function GetMemoryInfo(addr: NativeUInt): TMemoryBasicInformation; inline;
begin
  VirtualQuery(Pointer(addr), Result, SizeOf(Result));
end;

procedure TerminateRecoveringAfterStackOverflow;
begin
  Assert(restoringAfterStackOverlow);
  MessageBox(0, 'Не удалось восстановится после StackOverflow, приложение будет закрыто.',
    'Все пропало',
     MB_ICONERROR);
  Halt(0);
end;

function RestoreStackPageGuard(APageAddress: Pointer): boolean;
var
  oldProtectFlag: dword;
begin
  result := VirtualProtect(APageAddress, PageSize, PAGE_READWRITE or PAGE_GUARD, oldProtectFlag);
end;

procedure StartRecoveringAfterStackOverflow;
begin
  Assert(not restoringAfterStackOverlow);
  restoringAfterStackOverlow := true;
  RestoreStackPageGuard(GetSegmentStackTop);
  Application.OnMessage := Form1.DoOnMessage;
end;

procedure StopRecoveringAfterStackOverflow;
begin
  Assert(restoringAfterStackOverlow);
  restoringAfterStackOverlow := false;
  Application.OnMessage := nil; // Так конечно лучше не делать, а использовать для этих
                                // целей вместо обработчика OnMessage хук на сообщения
end;

procedure ValidateStackPageGuards;
var
    memoryInfo: TMemoryBasicInformation;
    address, stackLimit: NativeUInt;
    guarded: Boolean;
begin
  address := NativeUInt(GetESP);

  guarded := False;
  address := NativeUInt(GetMemoryInfo(address).BaseAddress);
  stackLimit := NativeUInt(GetSegmentStackTop);


  while not(guarded) and (address >= stackLimit) do
  begin
    memoryInfo := GetMemoryInfo(address);
    guarded := (memoryInfo.Protect and PAGE_GUARD) = PAGE_GUARD;
    address := address - PageSize;
  end;

  if not guarded then
  begin
    TerminateRecoveringAfterStackOverflow;
  end;
end;


function _RaiseExeceptionProc(P: PExceptionRecord): Pointer{Exception};
begin
  if (GetCurrentThreadId = MainThreadID)  then
  begin
    if not restoringAfterStackOverlow then
    begin
      if Assigned(P) and (P.ExceptionCode = STATUS_STACK_OVERFLOW) then
      begin
          StartRecoveringAfterStackOverflow();
      end
    end else
      ValidateStackPageGuards;
  end;

  if Assigned(oldRaiseExceptionProc) then
    result := oldRaiseExceptionProc(P);
end;



procedure WeNeedToGoDeeper(var i : integer);
var
  a:array[0..4000] of char;
begin
  inc(i);
  WeNeedToGoDeeper(i);
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  i: integer;
begin
  i := 0;
  try
    WeNeedToGoDeeper(i);
  finally
     MessageBox(0,  PChar(Format('На %d вложение',[i])), 'Ошибка StackOverflow', mb_ok);
  end;
end;

procedure TForm1.DoOnMessage(var Msg: TMsg; var Handled: Boolean);
var
  i: integer;
begin
  Assert(restoringAfterStackOverlow);
  ValidateStackPageGuards;

  for i := 1 to 16 do
  begin
    if not RestoreStackPageGuard(Pointer(NativeInt(GetSegmentStackTop) + PageSize * i)) then
    begin
      TerminateRecoveringAfterStackOverflow();
    end;
  end;
  StopRecoveringAfterStackOverflow();
end;

initialization
  stackGuaranteeSize := PageSize * 16;
  SetThreadStackGuarantee(stackGuaranteeSize);

  oldRaiseExceptionProc := ExceptObjProc;
  ExceptObjProc := @_RaiseExeceptionProc;
end.

Проверить, что восстановление после StackOverflow работает можно с помощью утилиты  vmmap из SysInternalsSuite.

Первый скриншот после запуска приложения. 16 кБ используется стеком из 1МБ. 68 кБ защищенная область.

Сразу после StackOverflow. Вся память выделена.

После восстановления работоспособности.

Более подробно о работе стека можно почитать тут:

1. MSDN http://msdn.microsoft.com/ru-ru/library/windows/desktop/ms686774(v=vs.85).aspx
2. У Джефри Рихтера в книге "Создание эффективных WIN32-приложений"
3. У Марка Руссиновича в блоге http://blogs.technet.com/b/markrussinovich/archive/2009/07/08/3261309.aspx и книге "Внутреннее устройство Microsoft Windows"