Мимопроходящийсреда задумалась немного, затем Execution Point встала на function _IntfClear(var Dest: IInterface): Pointer;
Как это может быть, если ты бряк ставишь внутри функции FinalizeUnits, а не _IntfClear? Точно всё правильно сделано было?
Возможно, у тебя исходник модуля System не соответствует бинарнику? Такое бывает в среде после всяких "хот патчей". Тогда ой. Можно попробовать восстановить соответствие, добавляя или удаляя пустые строки в модуль System выше по тексту. Ориентироваться можно на синие точке в редакторе - должны соответствовать тексту.
Вон там Finalization в стеке, кстати. Это - что? Если два раза по нему щёлкнуть? Попадём в нужный unit?
Насчёт EurekaLog 4 - это что-то совсем старое, но принцип должен быть тот же:
1.
2.
3.
4.
5.
6.
var
Buffer[0..99] of Byte;
begin
// нет FillChar
// ...
end;
Этот код оставит на стеке мусор от предыдущих вызовов - в том числе, старые адреса возврата. Следовательно, RAW-трассировка увидит эти вызовы и они будут в стеке. Это ложно-положительные вызовы.
Но почему отсутствует строка для finalization на стеке - вопрос. Возможно, что-то не так с отладочной инфой? Если среда старая - там глюки линкера бывают. Если новая - EurekaLog 4, возможно, не знает как правильно с ней работать. Что-нибудь, типа деструкторов класса.
Если совсем никак - можно стек вручную раскрутить. Открой CPU отладчик, там в окне стека правой кнопкой по значениям и Follow -> Near Code. Как только увидел какой-то модуль: это - оно. Можно по адресам угадывать, какие точно значения можно пропустить. 0019что-нибудь - это стек, пропускаем. 7что-нибудь - ядро, пропускаем. 0что-нибудь - какие-то DLL, можно проверить. 004что-нибудь-00Fчто-нибудь - твой exe-шник, это смотрим. У меня в отладчике примерно 30 значений между вылетом и модулем, из которых я проверил только четыре, все остальные - явно "левые".
