Вышла новая версия компилятора FreePascal

[Mikhail]

Ещё один изобретатель собственной терминологии?

Напротив это Вы и автор статьи в Википедии изобретатели. Еще раз утечка ресурса это потеря указателя, дескриптора и физическая невозможность освободить ресурс. А то о чем Вы говорите - следствие кривой архитектуры, как правило.

[sts]

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

[kazalex]

Напротив это Вы и автор статьи в Википедии изобретатели.

А гуглить и читать у тебя не получилось, стало быть? Если в системах с GC утечек нет, чего же народ активно ищет способы борьбы с ними, а другие люди об этих способах рассказывают

Еще раз утечка ресурса это потеря указателя, дескриптора и физическая невозможность освободить ресурс. А то о чем Вы говорите - следствие кривой архитектуры, как правило.

Совершенно фиолетово, что явилось результатом невозможности осовобождения памяти. Главное, что появился кусок памяти/ресурс, который приложению не нужен, но при этом и освобождён быть не может. Конечно механика возникновения будет разной, ведь модель работы с памятью тоже разная. В нативе забыли позвать, условно, free и получили утечку, в дотнете забыли отписаться от события (чтоб ты не думал, будто пример из вики единственный) и получили её же, в конечном итоге.

[Mirage]

Утечка памяти - чаще всего результат ошибки программиста. Без GC это банально не освобожденная память. При наличии GC, например, объекты, добавленные в статическую мапу и не убранные оттуда. Конечно, с GC возможностей для этого меньше, но все равно есть.

[bormant]

Лекс Айрин,
viewtopic.php?f=1&t=10762&view=unread#p92199
Преобразование локальных переменных в глобальные вряд ли какой компилятор Паскаля будет делать. Начнем с того, что разные сегменты, стек и данные. Этим, пожалуй, можно и закончить.

[Mikhail]

Совершенно фиолетово, что явилось результатом невозможности осовобождения памяти. Главное, что появился кусок памяти/ресурс, который приложению не нужен, но при этом и освобождён быть не может.

Так нет невозможности освобождения памяти! Технически блок доступен по ссылке, а следовательно может быть освобожден!
Такой код тоже "утечка" памяти?

Код: Выделить всё

procedure Test(a,b,c);
var p: pointer;
begin
...
GetMem(p, size);
...
//тут p уже не нужно
Test(a,b,c);
FreeMem(p);
...
end;


Не нужно выдумывать альтернативную терминологию. Еще раз утечка это потеря дескриптора или указателя и техническая невозможность освободить блок! В GC же блок будет освобожден, когда-нибудь... да-да в спецификациях прямо так и написано .

И еще, я уже писал, что GC не освобождает от необходимости думать о работе с памятью и, тем более, о работе с другими типами ресурсов.

Добавлено спустя 47 секунд:

Утечка памяти - чаще всего результат ошибки программиста.

Это всегда - ошибка програмиста.

[kazalex]

Технически блок доступен по ссылке, а следовательно может быть освобожден!

Технически, в нативе, менеджер памяти тоже имеет ссылку на блок, следовательно, он его когда нибудь освободит (а ещё и по завершению приложения ОС грохнет все связанные с аппой ресурсы ). Упс, в нативе, оказаывается, тоже нет утечек.

Не нужно выдумывать альтернативную терминологию.

Это как раз то, о чём я тебе сразу сказал.

[Дож]

Mikhail, в этом коде есть утечки?

Код: Выделить всё

unit wrapper;

interface

type
ICallback = interface
  procedure Callback;
end;

TMyCallbackWrapper = class(TInterfacedObject, ICallback)
private
  FFatness: array[0..1024*1024] of Byte;
public
  constructor Create;
  procedure Callback;
end;

implementation

var
  Callbacks: array of ICallback;

constructor TMyCallbackWrapper.Create;
begin
  SetLength(Callbacks, Length(Callbacks) + 1); // аналогичный вопрос если закомментить
  Callbacks[High(Callbacks)] := Self;          // эти две строки
end;

procedure TMyCallbackWrapper.Callback;
begin
  Writeln(PtrUInt(Self), ' ', Length(Callbacks), ' ', FFatness[554]);
end;

end.


Код: Выделить всё

program leaks;

uses
  wrapper;

procedure Test;
var
  Callback: ICallback;
begin
  Callback := TMyCallbackWrapper.Create;
  Callback.Callback;
end;

begin
  while True do Test;
end.


Указатель мы не потеряли, техническая возможность освободить врапперы есть, следовательно — утечек нет?

[Mikhail]

Mikhail, в этом коде есть утечки?

Нет. С таким же успехом можешь попытаться загрузить 100 Гб файл в ОЗУ.

Добавлено спустя 55 секунд:

Технически, в нативе, менеджер памяти тоже имеет ссылку на блок, следовательно, он его когда нибудь освободит (а ещё и по завершению приложения ОС грохнет все связанные с аппой ресурсы ). Упс, в нативе, оказаывается, тоже нет утечек.

А еще можно питание выключить, не передергивай.

[Дож]

С таким же успехом можешь попытаться загрузить 100 Гб файл в ОЗУ.

нет, это совсем не то же самое, что загрузить 100Гб в память: здесь память теряется постепенно и итеративно, с точки зрения написавшего программу leaks всё корректно, а написавший wrapper, возможно, плохо подумал и не предусмотрел возможность освобождения объектов. Такая ситуация могла возникнуть в реальности (например, в каком-нибудь демоне, при выполнении операций создающем такие интерфейсы).

Хоть тут нет технических утечек, на практике это имеет такие же неприятные последствия, т.е. внезапное OutOfMemory, которого вроде бы быть не должно, — и если это действительно внезапно, то при отладке этот баг будет проходить по статье «поиск утечки памяти», а не «переделка архитектуры приложения».

[Mikhail]

Хоть тут нет технических утечек, на практике это имеет такие же неприятные последствия, т.е. внезапное OutOfMemory, которого вроде бы быть не должно

Это ошибка в плохо спроектированном программном модуле. Опять же, например, если алгоритм предполагает сначала загрузку в память всех данных, а потом их полную обработку, а данных слишком много и получишь OutOfMemory это что утечка? Если временные данные не влезли в ОЗУ это утечка? Это архитектурные проблемы, которые не решаются ни GC ни чем-либо другим, кроме разработчика.

[kazalex]

А еще можно питание выключить, не передергивай.

Это я, блин, передёргиваю? Я же тебе ясно сказал:

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

В ответ читаю фееричное заявление о "технически доступном по ссылке блоке" :facepalm:

[Mikhail]

Это я, блин, передёргиваю?

Да передергиваешь. Мы не о механике, а о терминологии. Для программы менеджер памяти это черный ящик с функциями дать ссылку и освободить ссылку, программы внутренняя структура менеджера недоступна. Что касается ОС, то на ее уровне фактически работает GC.

[kazalex]

Мы не о механике, а о терминологии

Я тебе уже дважды предлагал погуглить, и даже фразу указал по какой (увидишь, кто тут не дружит с терминологией). Более того, я тебе сказал:

Совершенно фиолетово, что явилось результатом невозможности осовобождения памяти. Главное, что появился кусок памяти/ресурс, который приложению не нужен, но при этом и освобождён быть не может.

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

внутренняя структура менеджера недоступна

Фигню ты говоришь. У FastMM, например, можно получить полное состояние менеджера, с картой памяти, пулами блоков и их размерами. Более того, менеджер памяти можно заменить на собственный, со своим механизмом трейсинга. Это если ты хочешь продолжать о "технически...".

[Mikhail]

Я тебе уже дважды предлагал погуглить, и даже фразу указал по какой (увидишь, кто тут не дружит с терминологией). Более того, я тебе сказал:

В интернете много чего можно нагуглить и что из этого? Не все что написано на заборе есть истина.

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

код показывает что можно исчерпать всю память (а можно и не исчерпать, если повезет), при этом он не содержит утечки памяти. Просто неверно построен. Не нужен - значит на него нет ссылки, если ссылка есть значит нужен.

Фигню ты говоришь. У FastMM, например, можно получить полное состояние менеджера, с картой памяти, пулами блоков и их размерами. Более того, менеджер памяти можно заменить на собственный, со своим механизмом трейсинга. Это если ты хочешь продолжать о "технически...".

А еще можно отладчик запустить и поправить ссылку.