Разница между интерфейсами в Delphi 7 и Delphi 2007

У нас проблема с утечкой памяти, которая происходит только во время работы приложения (при закрытии приложения отчета FastMM нет).

Мы отделяем проблему от метода, который считывает значения из базы данных и создает экземпляры объектов из результата. (мы используем DBXPress для подключения к базе данных)

Класс, выполняющий работу с базой данных, реализует интерфейс. Используя тестовое приложение, которое ничего не делает, кроме запуска потока, считывающего значения из базы данных (всегда одни и те же значения), приложение в Delphi 7 не допускает утечек. Но в Delphi 2007 использованная память скачивается очень быстро. Это тот же код, то же тестовое приложение.

Когда вы проверяете приложение с помощью AQTime, вы можете видеть, что количество TStringList, TList и т. Д. (Всех объектов, используемых классом базы данных) растет и сжимается, но при проверке памяти с помощью ProExplorer и диспетчера задач Windows версия Delphi 2007 растет очень быстро. .

Мы можем только догадываться, что есть что-то другое в том, как Delphi 7 и Delphi 2007 занимаются выпуском интерфейса. Имеет ли это смысл? Кто-нибудь испытывал нечто подобное?


memory-leaks interface delphi delphi-7 delphi-2007
person ronaldosantana    schedule 17.03.2011    source источник
comment
Если FastMM не сообщает об утечке, значит, утечки нет. Или, если есть утечка, это память, выделенная другим распределителем, например в сторонней DLL.   -  person David Heffernan    schedule 17.03.2011
comment
Теперь, когда вы упомянули, другое отличие состоит в том, что в Delphi 2007 мы используем dbxINT30.dll Это похоже на версию Delphi 7 (или версию DLL на Delphi 7), по какой-то причине знаете, как освободить память и т. Д., Но с версией Delphi 2007 он просто продолжает расти - когда близко, отчета об утечке нет, но что-то действительно не так ...   -  person ronaldosantana    schedule 17.03.2011
comment
@david: FastMM будет сообщать только об утечках, которые остаются утечками в конце программы. Если во время выполнения происходит утечка памяти, которая каким-то образом очищается перед завершением программы, FastMM не считает это утечкой. Я удивлен, что кто-то с вашим опытом этого не знает. ;)   -  person Deltics    schedule 17.03.2011
comment
@david, продолжение: Пример: форма, которая создает собственный компонент в ответ на какое-то событие, когда она должна сначала создать один такой компонент и повторно использовать его в последующих событиях. Когда форма закрывается, вытекшие компоненты очищаются, потому что они принадлежат форме. Что касается обнаружения утечек FastMM, это не утечка, но тем не менее это утечка в той форме, которая потенциально может привести к повреждению вашего приложения.   -  person Deltics    schedule 17.03.2011
comment
Возможно, в новой DLL память выделяется напрямую в обход FastMM (см. stackoverflow.com/questions/4477936/)   -  person mjn    schedule 17.03.2011
comment
@Deltics: Туше! Я знаю это, но никогда не рассматриваю это, потому что я лично никогда не использую свойство Owner для освобождения объектов, которые я создаю в коде. Естественно, я использовал его для потоковых компонентов, но я всегда пишу пары Create / Free в блоках Try / finally. Так что такого рода утечки просто не на моем радаре, но я согласен, что это может быть проблемой здесь.   -  person David Heffernan    schedule 17.03.2011
comment
@David: Механизм владельца - это только один пример. Может существовать любое количество механизмов, которые обеспечивают неполное управление памятью во время выполнения, но не приводят к утечке при завершении процесса.   -  person Deltics    schedule 17.03.2011
comment
@Deltics Это, наверное, главный в программе Delphi. Какие еще механизмы вы придумываете   -  person David Heffernan    schedule 17.03.2011
comment
@ Дэвид: Я не говорю о запрещенных или стандартных механизмах. Мы можем заставить это программное обеспечение делать все, что захотим. Авторы VCL предоставили механизм владельца для управления временем жизни определенных объектов с определенными отношениями друг с другом. В нашем собственном коде мы имеем в своем распоряжении бесконечное множество средств для реализации подобных вещей. Я имею в виду ЭТО, а не конкретную реализацию. VCL Owner - это всего лишь ОДИН конкретный пример, который я предоставил как иллюстрацию того, что я имел в виду. Я не могу знать, какие подобные механизмы могут быть в собственном коде OP.   -  person Deltics    schedule 18.03.2011
comment
@Дэйвид. cont: Дело просто в том, что FastMM будет сообщать только об определенных типах утечек памяти, то есть тех, которые остаются утечкой при завершении процесса. Но есть и другие типы утечек памяти, утечки, которые закрываются ДО завершения программы, и FastMM НЕ поможет вам их найти.   -  person Deltics    schedule 18.03.2011
comment
@Deltics Согласен. Однако FastMM по-прежнему полезен!   -  person David Heffernan    schedule 18.03.2011
comment
FastMM полезен при обнаружении утечек, которые может обнаружить FastMM. Для всех других типов утечки памяти по определению следует использовать МЕНЬШЕ. Дайте кому-нибудь молоток, и, кажется, некоторые люди тогда начнут видеть все как гвоздь ...;)   -  person Deltics    schedule 18.03.2011

Ответы (1)


arrow_upward
3
arrow_downward

Ну ... Мои 2 цента:

В том, как delphi 2007 работает с интерфейсами, нет ничего необычного. Но давным-давно у меня была аналогичная проблема с интерфейсами, и я вообще не использовал счетчик ссылок на интерфейс. Это не очень хорошо работает.

Вы не разместили свой источник, но я предполагаю, что ваши объекты, реализующие интерфейс, наследуются от TInterfacedOject, я прав? Если это так, подумайте о том, чтобы изменить его на собственный TInterfacedObject, который не будет реализовывать методы подсчета ссылок. Вам придется уничтожать свои объекты вместо того, чтобы с ними разбираться delphi.

Еще одна вещь, которую вы можете подумать, - это сообщить delphi, что вам больше не нужен интерфейсный объект, установив nil для интерфейсного объекта, который вы не используете.

Но, как все говорили в комментариях, если fastmm не сообщает об утечке, то утечек нет вообще. Тот факт, что объем памяти быстро увеличивается, не означает, что ваша программа имеет утечку. Это лишь говорит о том, что вы не обращаете внимания на свои объекты, как хотели.

Вам следует использовать EurekaLog. Это очень хороший аддон, который сообщает об утечках памяти и их стеке вызовов.

Также обратите внимание на этот вопрос

person Rafael Colucci    schedule 17.03.2011
comment
Что касается ограничений FastMM, см. stackoverflow.com/questions / 4477936 / - person mjn; 17.03.2011
comment
Привет, @Rafael Colucci - ты прав насчет TInterfacedObject. Также спасибо за ссылку на другой вопрос и подсказку EurekaLog. - person ronaldosantana; 17.03.2011
comment
Нет проблем, но вы должны принять ответ, если он вам помог. - person Rafael Colucci; 18.03.2011