IntfClear

← →
Alkid © (2006-09-04 10:20) [0]

Есть в недрах Дельфишного rtl функция IntfClear, которая есть по сути деструктор указателя на COM-интерфейс (т.е. всего, что
наследовано от IUnknown).
Вопрос - можно ли как-нибудь легально, без изменения исходников System.pas заменить эту функцию на свою в отладочных целях?

Если нет, то другой вопрос - всегда ли rtl линкуется к программе статически или же может как и vcl - динамически?

← →
oxffff © (2006-09-04 10:27) [1]

IntfClear Очищает указатель и вызывает _Release.
Так может проще в _Release и вызывать процедурку для отладки?

← →
Сергей М. © (2006-09-04 10:28) [2]

> всегда ли rtl линкуется к программе статически

Не всегда.
Только при Build With Run-Time Packages = False

← →
oxffff © (2006-09-04 10:29) [3]

Alkid
>Есть в недрах Дельфишного rtl функция IntfClear, которая есть по сути >деструктор указателя на COM-интерфейс (т.е. всего, что
>наследовано от IUnknown).

Это не деструктор.

← →
Alkid © (2006-09-04 10:35) [4]

> Не всегда.
> Только при Build With Run-Time Packages = False

Хорошо, тогда как называется rtl-овский пакет?

> IntfClear Очищает указатель и вызывает _Release.
> Так может проще в _Release и вызывать процедурку для отладки?

Ситуация такова: в этой функции возникает исключение, как раз при обращении к _Release. Иными словами, где-то COM-объект удаляется нештаттно и при "зачистке" ссылки на него происходит вызов ._Release у уже мёртвого объекта.
У сожалению отладка с применением break-point`ов не даёт результата - при остановке на break-point исключение никогда не происходит, там явно race-condition. Иными словами, идентифицировать сам код, где "зачищается" указатель я пока не могу. Для этого я и хочу временно модифицировать IntfClear, что бы отловить там это каким-нибудь Assert`ом и раскрутить стэк вызовов до интересующего меня кода. Вот :)

> Это не деструктор.

Формально да, но он вызывается всегда при удалении переменной-ссылки, то есть по сути играет роль деструктора.

← →
oxffff © (2006-09-04 10:40) [5]

Этот проблеменый Interface ваш?
Или сторонний. Имеется ввиду есть исходники _Release.

← →
Alkid © (2006-09-04 10:43) [6]

> Этот проблеменый Interface ваш?
> Или сторонний. Имеется ввиду есть исходники _Release.

Наш, наш :-) Скорее всего даже мой. Исходники _Release там везде одни и те же, ибо всё наследуется от TInterfacedObject или TComObject...
Хотя уже спасибо, ты меня навёл на одну гениальную идею :)

← →
oxffff © (2006-09-04 10:48) [7]

Если ваш тогда.

_Release
....
Result := InterlockedDecrement(FRefCount);
if Result = 0 then Destroy;
............

Наверно на эту.

← →
Сергей М. © (2006-09-04 10:50) [8]

> как называется rtl-овский пакет?
>

Так и называется - rtl70.bpl (для случая с Д7)

← →
Alkid © (2006-09-04 10:56) [9]

> Result := InterlockedDecrement(FRefCount);
> if Result = 0 then Destroy;

Ну лично я этого кода не писал, но у меня появилась другая мысль - я
деструктор этих объектов (а львиная доля их наследуется от одного нашего класса) обложил Asset`ом FRefCount <= 0.

> Так и называется - rtl70.bpl (для случая с Д7)

То есть если его не указано в списке пакетов на динамическую линковку, то таки линкуется статически, да?

← →
Сергей М. © (2006-09-04 11:02) [10]

> если его не указано в списке пакетов на динамическую линковку,
> то таки линкуется статически, да?
>

Нет.
Если BwRTP=TRUE, то RTLXX.BPL линкуется динамически ВНЕ зависимости от того, перечислил ты этот пакет в списке пакетов или не перечислил.

Хм. Не знаю как в семёрке, но у меня на пятом я не вижу в списке загруженных модулей что-то похожее на rtl-пакет при BwRTP=TRUE. Видим тт уже сказывается
разница в версиях. Но всё равно спасибо, совместными усилиями вы натолкнули меня на идею, как решить проблему :)

> Alkid © (04.09.06 11:07) [11]

В 5-ке, насколько помнится, файл RTL-пакета как таковой отдельный не существует - там RTL и VCL объединены в VCL50.bpl

Наш, наш :-) Скорее всего даже мой. Исходники _Release там везде одни и те же, ибо всё наследуется от TInterfacedObject или TComObject...

Так вам нужно понять где очищается.

TInterfacedObject._Release
....
Result := InterlockedDecrement(FRefCount);
if Result = 0 then Destroy;
....

Ставим бряк на destroy; После выхода попадаем IntfClear.
После выхода попадает либо в конец нужной процедуры\функции, либо
TObject.CleanupInstance;

Возможно гдето явно вызывается деструктор объекта, поэтому в деструкторе напиши первой строчкой
if RefCount <> 0 then Exit;

IntfClear Найти похожие ветки