The Delphi Survey is now available in Russian!
http://video.codegear.com/survey/2008DelphiSurvey_Russian.html

Ответ на »сообщение 813« (Aleg Azarousky)
___________________________
Неплохая мысль! А может быть сделать еще такой режим, в котором память бы вообще не возвращалась, а выделялась бы каждый раз в новом месте? Конечно, память, скоро бы закончилась, но возможно за это время мы сумели бы найти ошибку. И еще функцию, которую показывала, что есть записи в освобожденной области памяти?

Ответ на »сообщение 812« (Стэн)
___________________________
Да, я тоже подумал, что для целей тестирования в FastMM в режиме отладки могли бы давать место для новых объектов за только что освобожденными. А когда остается мало свободной памяти - снова начинаем распределять память сначала кучи. Тогда такая ошибка, как указана ниже, сразу давала бы Access violation at address 80808080.
Может грамотно сформулировать по английски и подкинуть идею разработчику?

Ответ на »сообщение 810« (Aleg Azarousky)
___________________________
Кстати, хочу заметить, что любой приличный алгоритм GC всегда размещает новые объекты в области памяти, которая инициализирована нулями. Но что самое важное, всегда в дргугое место. Поэтому никогда не бывает ни каких коллизий и неправилных присваиваний. А вот для обычного менеджера памяти, создавать объект каждый раз в новом месте - непозволительная роскошь, так как будет очень большая фрагментация памяти.

Ответ на »сообщение 809« (Сергей Перовский)
___________________________

Ответ на »сообщение 808« (lein)
___________________________
Я, пожалуй, вполне мог бы обойтись без сборщика мусора в будущей версии Delphi, если каждое обращение к освобожденному объекту гарантировано вызывало бы исключение.
Вместо Free используйте везде  FreeAndNull и будет Вам счастье.
К сожалению FreeAndNil не сделает жизнь счастливой.
Во-первых, как заметил  Aleg Azarousky в сообщении 810, обращение к свойству нулевого объекта может не вызвать исключение, тем самым только маскируя ошибку.
Во-вторых, FreeAndNil освобождает память объекта, но очищает только один указатель на него и обращение к несуществующему объекту может остаться через другой указатель:

procedure TForm1.Button6Click(Sender: TObject);
var
  b, b2: TButton;
  f : TForm1;
begin
  b := TButton.Create(self);
  b2 := b;
  FreeAndNil(b2);
  f := TForm1.Create(self);
  f.Caption := 'asdfg';
  b.Caption := 'qwerty';//обращение к несуществующему объекту
  b2.Caption := 'qwerty';//обращение к нулевому объекту без сообщения об ошибке
  f.Show;
end;

В-третьих, иногда приходится искать  ошибки в чужом коде.
Подобная ошибка есть в известной библиотеке Ehlib версия 4.2.
В библиотеке есть классы  TDBGridInplaceEdit (редактор ячейки) и TColumnEh (колонка) со свойством MRUList.
У DBGridInplaceEdit и TColumnEh может быть один и тот же объект MRUList.
При разрушении колонки в процедуре TColumnEh.Destroy (DBGridEh.pas) происходит и разрушение MRUList - FreeAndNil(FMRUList). Замечу, что FreeAndNil, а не FMRUList.Free, но это не предотвращает ошибку! 
При потере фокуса редактором ячейки в процедуре TDBGridInplaceEdit.WMKillFocus (DBGridEh.pas) происходит обращение к несуществующему объекту MRUList, что и вызывает ошибку. Проявлялась она у меня в самых неожиданных местах программы, и я очень долго искал ее причину.

Ответ на »сообщение 808« (lein)
___________________________
ОЧень интересный пример!
Если мы отключаем f: TForm1;, т.е.

begin
  b := TButton.Create(self);
  b.Free;
  b.Caption := 'qwerty';//обращение к несуществующему объекту
end;

то получим именно то что нужно - Access violation at address 80808080.
Что происходит после инициализации f: TForm1? Похоже, распределение памяти в VCL происходит так, что новый button f.Button1 ложится именно в то место в памяти, которое занимал b. Т.е. b начинает указывать на кнопку во вновь созданной форме, и обращение к b уже не вызывает ошибки, т.к. этот участок памяти снова распределен.

Выходит да - FastMM не может ловить все возможные проблемы с указателями.

Интересно, что если мы напишем так:

var
  b: TButton;
begin
  b := Nil;
  b.Caption := 'qwerty';//обращение к несуществующему объекту
end;

то ошибки тоже не будет! Как выяснилось, в VCL в function TControl.Perform идет тестирование ссылки на объект:

if Self <> nil then WindowProc(Message);

хотя по идее должно быть

if Self = nil then raise Exception('Access to uninitialized object!!!');

Ответ на »сообщение 808« (lein)
___________________________
Я, пожалуй, вполне мог бы обойтись без сборщика мусора в будущей версии Delphi, если каждое обращение к освобожденному объекту гарантировано вызывало бы исключение.
Вместо Free используйте везде  FreeAndNull и будет Вам счастье.

Ответ на »сообщение 807« (Aleg Azarousky)
___________________________
Благодарю за совет использовать FastMM! Сегодня его скачал. Очень полезный инструмент. Я пользуюсь обычно Delphi 5, в состав которого FastMM не входит, и поэтому не знал об его отладочных способностях.
Однако всех проблем, связанных с обращением к освобожденным объектам, мне кажется, менеджер памяти решить не может, в том числе FastMM.
Например, в следующем, явно неверном коде FastMM (с опциями UseRuntimePackages, FullDebugMode, ClearLogFileOnStartup) не находит никаких ошибок:

procedure TForm1.Button4Click(Sender: TObject);
var
  b : TButton;
  f : TForm1;
begin
  b := TButton.Create(self);
  b.Free;
  f := TForm1.Create(self);
  f.Caption := 'asdfg';
  b.Caption := 'qwerty';//обращение к несуществующему объекту
  f.Show;
end;

Возможно, я еще не разобрался с FastMM. В данном случае обращение к несуществующей кнопке модифицирует первую кнопку на форме f.
Я, пожалуй, вполне мог бы обойтись без сборщика мусора в будущей версии Delphi, если каждое обращение к освобожденному объекту гарантировано вызывало бы исключение. Но, наверное, сделать это также сложно, как сделать GC.

Ответ на »сообщение 806« (lein)
___________________________
Конечно! FastMM - встроенный менеджер памяти.

Q: My program used to work fine, but if I enable "FullDebugMode" and run it I get an access violation at address $8080xxxx. Why?
A: You are attempting to access properties of a freed object. When you free a block in "FullDebugMode", FastMM fills the freed memory area with a pattern of $80 bytes. If there were any pointers, long strings or object references inside the freed object they will now point to $80808080 which is in a reserved address space.

И еще про двойное освобождение объектов:
Q: My program used to work fine with the Borland memory manager, but I get an "Invalid Pointer Operation" or "Access Violation" with FastMM. Is there a bug in FastMM?
A: Highly unlikely. The memory manager is such a critical part of any program and is subjected to such a large amount of traffic that it is rare that a bug of this nature will make it through testing. FastMM works differently than the default memory manager and does more pointer checking, so it will catch more errors. For example: The default MM may allow you to free the same pointer twice while FastMM will immediately raise an "Invalid Pointer Operation" if you try to do so. Compile your application with the "CheckHeapForCorruption" option set in FastMM4.pas - this should raise an error closer to the source of the problem.

Трудно отлавливаемая ошибка в Delphi – обращение к уже освобожденному объекту. Это, на мой взгляд, хуже, чем утечка памяти. Ошибка неприятна своим случайным характером. Хорошо, если сразу возникнет Access violation. Ошибка может проявиться позже в модуле, не имеющем никого отношение к причине ошибки.
В языках с GC такой проблемы нет, а в известных мне языках без GC есть,  и как мне кажется, неизбежна для сложных программ.
Но, может быть, я ошибаюсь, и для  Delphi уже сейчас есть методы локализации подобных ошибок?  Какой-нибудь особенный менеджер памяти?