Как найти повисший интерфейс, который вызывает AV в Delphi

В большинстве случаев такие ошибки могут быть обнаружены с помощью FastMM и компиляции приложения с условными определениями FullDebugMode и CatchUseOfFreedInterfaces . Просто убедитесь, что вы поставили FastMM4 на первое место в списке «использует» dpr.

Может быть, с помощью такого инструмента, как EurekaLog? http://delphi.about.com/od/productreviews/ss/eurekalog.htm

Шаги для поиска проблемы:

1. Используйте FastMM в режиме полной отладки, как предложил Gabr (я думаю, что вы уже это сделали, глядя на шаблон 808080).
2. Установите все интерфейсы, которые вы используете в классе, явно на nil в процедуре Destroy
3. Поставьте точку останова в начале процедуры Destroy
4. Теперь пройдите через процедуру Destroy, при уничтожении висящего интерфейса вы получите Access Violation и узнаете, какой это был интерфейс.
5. Когда у вас все еще есть AV после того, как вы без проблем уничтожили все интерфейсы, выполните шаги 2 - 5 для родительского класса.

У меня тоже были такие проблемы, и описанный выше метод помог мне найти их. Мои проблемы были вызваны TComponents, которые реализовывали интерфейсы. Скажем, у вас есть ComponentA и ComponentB, ComponentB реализует интерфейс. Вы присваиваете ComponentB (или его интерфейс) ComponentA и сохраняете ссылку на интерфейс. Теперь ComponentB уничтожается, но ComponentA не знает об этом. Когда вы уничтожаете ComponentA, он закрывает интерфейс, вызывает метод _Release, и вы получаете AV.

Решением этой проблемы является работа с TComponent.FreeNotification. Когда вы получаете бесплатное уведомление от ComponentB, вы обнуляете интерфейс в ComponentA. Я ничего не знаю о вашем коде, но если ваша проблема похожа, вы можете работать и с FreeNotifications.

Edit: добавлен шаг 5

Одна вещь, которую следует искать в вашем коде, это следующее

FInterfacedObject.GetInterface 

в той же области видимости, что и

FInterfacedObject := TInterfacedObjectClass.Create.

где FInterfacedObject - переменная класса.

Вы можете вызвать GetInterface из внутренней функции, если хотите, но если вы вызовете GetInterface в той же области видимости, в которой вы создали FInterfacedObject, по какой-либо причине вы сбросите счетчик ссылок до 0 и освободите вещь, но она не станет nil, так что если вы сделаете

if assigned(FInterfacedObject) then
    FInterfacedObject.Free;

вы получите нарушение доступа.

Похожая ошибка, которая укусила меня, была ссылка на интерфейс, которая была установлена ​​для существующего объекта, счетчик ссылок интерфейса не будет уменьшаться автоматически при освобождении объекта-владельца. Это можно решить с помощью if Assigned (FMyInterface), затем FMyInterface: = nil; в деструкторе объекта-владельца.

Я делаю похожее, и следующий код в деструкторе вашего объекта поможет

Destructor TMyObjectThatIAmDoingManualRefCounting.Destroy;
begin
  if FMyRefCount<>0 then
    messageDlg('You dork, you called Free on me when someone still had references to me');

  inherited;
end;

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

Другая вещь, которую вы можете сделать, это поставить точки останова в ваших методах addref и release и проследить, кто хранит интерфейсные ссылки и освобождают ли эти же объекты их после этого.

Также распространенной проблемой является следующее: если вы получаете интерфейс и освобождаете объект в том же методе

var
  o:TSomeObject;
begin
  o:=TSomeObject.Create;
  (o as ISomeInterface).DoSomething;
  o.free
end;

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

вам нужно сделать вот так

var
  o:TSomeObject;
  i:ISomeInterface;
begin
  o:=TSomeObject.Create;
  i:=(o as ISomeInterface); // or Supports or whatever
  i.DoSomething;
  i:=nil;
  o.free
end;