Delphi Seattle: я получаю операцию Invalid Pointer при освобождении созданного объекта

Понятно, что вы дважды освобождаете объект Loan, поэтому и получаете ошибку. Вам нужно освободить его только один раз. fmLoanRequests создает объект, но вы говорите, что он может быть закрыт до закрытия fmLoan, поэтому fmLoan должен стать владельцем объекта и освободить его, когда fmLoan закроется. Не освобождайте объект вообще, когда fmLoanRequest закрыт.

Альтернативой является определение интерфейса ILoan, который реализуют TLoan и потомки, а затем передача ILoan вместо TLoan напрямую. Интерфейсы подсчитываются по ссылкам, поэтому объект Loan будет освобожден автоматически и только один раз, после того как fmLoanRequests и fmLoan освободит свои ссылки на него.

Я добавил эту строку, чтобы убедиться, что объект будет освобожден, если fmLoan по какой-то причине не справится с ним. Я понимаю, что к этому моменту объект был освобожден, но разве if Assigned() не должно предотвращать ненужное освобождение объекта?

Это ключевое недоразумение. Рассмотрим следующую программу:

{$APPTYPE CONSOLE}

var
  obj: TObject = nil;

begin
  Writeln(Assigned(obj));

  obj := TObject.Create;
  Writeln(Assigned(obj));

  obj.Free;
  Writeln(Assigned(obj));

  Readln;
end.

Это выводит следующее:

FALSE
TRUE
TRUE

Обратите внимание, что последняя строка вывода — TRUE. Другими словами, когда вы уничтожаете объект, вызывая его метод Free, ссылочной переменной не присваивается значение nil.

Ваша ошибка в том, что вы считаете, что Assigned проверяет, был ли объект уничтожен. Это не так. Он просто проверяет, является ли ссылочная переменная nil или нет. Давайте еще раз посмотрим на код более подробно.

obj := TObject.Create;

Здесь мы создаем новый объект, размещенный в куче, с вызовом TObject.Create. Мы также присваиваем obj адрес или ссылку на этот объект. После выполнения этой строки obj становится ссылочной переменной, содержащей адрес допустимого объекта.

obj.Free;

Это уничтожает объект, на который ссылается obj. Запускается деструктор, после чего память уничтожается. После выполнения этой строки объект был уничтожен, но obj по-прежнему относится к этому уничтоженному и теперь недействительному фрагменту памяти. Вот почему Assigned(obj) дает true.

Примечание. Очевидно, я не использую указатели.

Это интересный момент. На самом деле вы используете указатели всякий раз, когда используете ссылочную переменную. Хотя язык скрывает этот факт, переменная ссылки на объект — не что иное, как указатель на память, выделенную в куче. Мы используем терминологию ссылка, а не указатель, но на самом деле это одно и то же. Они ведут себя одинаково, оператор присваивания имеет одинаковую семантику, вы по-прежнему подвержены потенциальной утечке, двойному освобождению, доступу после освобождения и всем другим ловушкам указателей. Таким образом, хотя вы явно не используете указатели, все же стоит думать о переменных ссылки на объект, как если бы они были указателями.

Я написал подробный ответ на всю эту тему для другого вопроса. Я предлагаю вам прочитать этот ответ: https://stackoverflow.com/a/8550628/505088.

Один из моментов, который вы уберете, это такой код, как

if Assigned(oLoan) then 
  oLoan.Free;

бессмысленно. Метод Free также проверяет, является ли ссылка на объект nil. Эта строка кода фактически расширена до:

if Assigned(oLoan) then 
  if Assigned(oLoan) then 
    oLoan.Destroy;

Итак, вместо

if Assigned(oLoan) then 
  oLoan.Free;

вы должны просто написать

oLoan.Free;

Теперь вернемся к нарушению доступа. Я думаю, что теперь должно быть очевидно, что вы пытаетесь уничтожить объект, который уже был уничтожен. Вы не должны этого делать. Вам нужно будет пересмотреть свой жизненный цикл. Рассуждения типа "если бы fmLoan по какой-то причине не разобрался с этим" действительно недостаточно хороши. Вы должны быть на 100% уверены в управлении жизненным циклом. Вы должны убедиться, что ваши объекты уничтожаются ровно один раз. Не имея возможности видеть весь ваш код, я не хочу давать конкретных рекомендаций.

Один шаблон, который иногда бывает полезен, заключается в установке ссылки на объект на nil при уничтожении объекта. Если объект может быть уничтожен в нескольких местах, этот метод можно использовать, чтобы убедиться, что вы не пытаетесь уничтожить его дважды. Вы даже можете использовать вспомогательную функцию FreeAndNil. Однако стоит подчеркнуть, что если вы не уверены, уничтожили ли вы уже объект, то это обычно свидетельствует о плохом дизайне. Если вы обнаружите, что хотите добавить вызовы Free, чтобы действовать «на всякий случай», то вы почти наверняка делаете что-то серьезно неправильное.