О чём не пишут в книгах по Delphi

begin
 Action := caFree;
end;

Обратите внимание, что в конструкторе сначала присваивается значение полю S, и лишь потом вызывается унаследованный конструктор. Это сделано потому, что по умолчанию S содержит пустую строку, т.е. nil, а уже при вызове унаследованного конструктора окно получит сообщения, для обработки которых будет вызван метод WndProc. Если в этот момент S будет по-прежнему nil, попытка обратиться ко второму символу строки вызовет Access violation. Поэтому еще до начала работы унаследованного конструктора поле S должно получить подходящее значение.

Запустим программу и попытаемся закрыть второе окно. Возникнет исключение Access Violation: Write of address 00000001. Проблема будет в строке, отмеченной {*}. При этом любые другие манипуляции с окном никаких исключений вызывать не будут.

При Action = caFree после завершения работы метода FormClose VCL вызывает метод TCustomForm.Release. Проблема именно в нем: если попытаться закрыть Form2 с помощью Release, возникнет то же самое исключение. В справке Release позиционируется как безопасный способ удаления формы из ее собственного метода. К сожалению, в действительности это не так: реализация этого удаления оставляет желать лучшего и может приводить к попыткам работать с объектом тогда, когда его уже не существует.

При вызове Release в очередь помещается сообщение CM_RELEASE, адресатом которого является сама удаляемая форма. В очередном цикле петли сообщений CM_RELEASE извлекается из очереди и передается на обработку. Так как сообщение адресовано форме, она же его и обрабатывает. Рассмотрим более подробно, как это происходит. (Детально механизм обработки сообщений в VCL описан в разд. 1.1.8; мы здесь рассмотрим только ту часть, которая относится к обработке CM_RELEASE.)

Система передает управление оконной процедуре. Для каждого экземпляра визуального компонента VCL создает свою оконную процедуру с помощью MakeObjectInstance. Эта процедура вызывает метод объекта MainWndProc, передающий управление тому методу, на который указывает свойство WindowProc. По умолчанию это WndProc. WndProc не обрабатывает CM_RELEASE самостоятельно, а передает его методу Dispatch. Dispatch пытается найти для этого сообщения специальный обработчик (метод с директивой message) и, т.к. в TCustomForm такой обработчик описан (он называется CMRelease), передаёт управление ему.

И здесь начинается самое интересное. CMRealease просто вызывает Free, удаляя тем самым объект, т.е. объект удаляется из метода самого объекта, что делать запрещено. Таким образом, после выполнения Free управление вновь получает CMRealease. Из него управление возвращается в Dispatch, оттуда — в WndProc, затем — в MainWndProc, далее — в оконную процедуру, и только после этого управление получает код, который никак не связан с конкретным экземпляром компонента. Мы видим, что после обработки CM_RELEASE и удаления объекта его методы продолжают работать. Методы уже не существующего объекта!

В принципе, методы несуществующего объекта могут вполне нормально завершить свою работу, если не будут обращаться к его полям или иным образом использовать указатель Self, который к этому моменту будет уже недействительным. Но стоило нам только вставить в один из этих методов код, задействующий поле объекта, как возникла ошибка. 

В данном примере получается следующее: сначала CM_RELEASE передаётся стандартному обработчику, который вызывает деструктор. При работе деструктора финализируются все поля объекта, для которых это требуется. В нашем случае это означает, что в поле S заносится nil (освобождения памяти при этом не происходит, потому что S до этого ссылалась на литерал, хранящийся в кодовом сегменте, а не в динамической памяти). После этого начинает работать наш код, который пытается изменить второй символ в строке. Программа пытается обратиться к ячейке с адресом nil + 1, т.е. 00000001, что и приводит к ошибке Access violation.

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

Посмотрим. что будет, если строку S[1] := 'x' заменить на S := IntToStr(Msg.Msg). Как мы уже выяснили, после уничтожения объекта в той области памяти, где хранилось значение S, будет nil. Указатель на вновь созданную строку будет помещен в эту область памяти. Но к ней уже не будет применяться финализация, т.к. менеджер памяти будет считать эту область памяти финализированной. Произойдет утечка памяти.

Отметим, что для вновь созданной строки память может быть выделена таким образом, что она наложится на те ячейки, в которых хранились значения полей уничтоженной формы, в том числе значение S. В этом случае попытка обратиться к такому полю приведет к непредсказуемым результатам.

Аналогичная проблема может появляться не только при перекрытии WndProc, а вообще при любом способе внедрения своего кода в цепочку обработки так, чтобы он выполнялся после CMRelease.

Совершенно непонятно, почему разработчики VCL реализовали такой заведомо некорректный механизм работы Release. Чтобы избежать всех описанных проблем, достаточно было бы просто посылать CM_RELEASE не самой форме, а окну, создаваемому объектом Application, а указатель на освобождаемую форму передавать через параметры этого сообщения. Тогда деструктор формы вызывался бы из метода объекта Application, и никаких проблем не было бы. 

Эта проблема обнаружена во всех версиях Delphi с 3-й по 2007-ю (в других версиях не проверялась). Самый простой способ ее преодоления — отмена опасных действий, если получено сообщение CM_RELEASE. Например, в описанном случае безопасным будет следующий код (листинг 3.53).

Листинг 3.53. Безопасный вариант метода WndProc

procedure TForm2.WndProc(var Message: TMessage);
begin
 inherited;
 if Msg.Msg <> CM_RELEASE then s[2] := 'x';
end;

Другой способ заключается в том. чтобы перенести обработку CM_RELEASE в объект Application с помощью его события OnMessage. Проблема заключается лишь в том, что адрес удаляемой формы будет неизвестен, но его легко найти по дескриптору окна. Например, в данном случае можно положить на первую форму TApplicationEvents и в его обработчике OnMessage написать следующий код (листинг 3.54; в примере CloseAV этот код закомментирован).