-
В стародавние времена для поиска утечек памяти пользовался я FastMMом. Всё было хорошо. Но теперь, в нынешнюю годину суровых испытаний, с появлением у меня Delphi XE8 я заметил, что FastMM больше не нужен, а достаточно лишь прямо в программе указать ReportMemoryLeaksOnShutdown := True. Вроде всё хорошо, но что-то не хорошо. А именно, раньше я мог сконфигурировать всё так, чтобы при выходе из программы ещё и файлик содавался, в котором указывалось, где утёкший блок был выделен. Теперь же можно только имя класса узнать, который утёк. Или всё таки можно как-нибудь изловчиться?
-
FastMM (если не считать что он уже внедрен в Delphi) нормально работает и ввиде старого варианта - с использованием внешней библиотеки, которая как раз и отвечает за создание данного лога.
-
Т.е. всё сделать как по старому и всё заработает? А если у меня 64-бита приложение? (А оно у меня реально 64 бита).
-
>
> Dimka Maslov © (23.03.16 20:53)
В Delphi насколько я знаю встроен урезанный FastMM4. Никто не запрещает подключить и обычный.
-
за 64 бита не подскажу - в 32 битах работает норм.
-
64 норм тоже. и да, в делфе вроде урезанный. я подключаю.
-
Понятно, спасибо.
Только вот ещё такой вопрос. Почему когда я внутри тела потока (в перекрытом методе Execute) делаю Free - оно ругается на невысвобожденную память из-под класса потока (хотя деструктор срабатывает и все поля объекты и строки высвобождены), а вот когда я указываю FreeOnTerminate := True и Terminate, то не ругается? Это очередной баг?
-
> Dimka Maslov © (24.03.16 08:38) [6]
Почему когда я внутри тела потока (в перекрытом методе Execute) делаю Free
Кому Free, экземпляру класса исполняемого потока???
-
> Кому Free, экземпляру класса исполняемого потока???
Кому же ещё?
-
То есть, создавался объект в одном потоке, а уничтожается в другом?
-
> То есть, создавался объект в одном потоке, а уничтожается
> в другом?
Что в этом плохого?
-
> Dimka Maslov © (24.03.16 10:45)
[8] Кому же ещё?Это потоковая функция:
function ThreadProc(Thread: TThread): Integer;
...
begin
...
try
if not Thread.Terminated then
try
Thread.Execute; <========= Вот тут Вы грохаете экземпляр
except
Thread.FFatalException := AcquireExceptionObject; <======= Далее по тексту идут обращения к грохнутому экземпляру
end;
finally
FreeThread := Thread.FFreeOnTerminate;
Result := Thread.FReturnValue;
Thread.DoTerminate;
Thread.FFinished := True;
SignalSyncEvent;
if FreeThread then Thread.Free; <=========== А тут экземпляр может еще раз грохнуться
...
end;
-
> Вот тут Вы грохаете экземпляр
В том и вопрос, что он вообще не грохается.
-
Грохается:
"... (хотя деструктор срабатывает и все поля объекты и строки высвобождены) ..."
И так делать нельзя (освобождать экземпляр класса TThread в методе Execute)!
"... а вот когда я указываю FreeOnTerminate := True и Terminate... "
Вот так, как выше написали, так и поступайте, раз Вам экземпляр после запуска потока не нужен.
-
В общем, CreateThread - Наше всё!
-
> Это очередной баг?Да , TThread это зло - BeginThread наше всё ))
Free -> WaitForSingleObject(FHandle, INFINITE);
-
> Dimka Maslov © (24.03.16 14:10) [14]
Да почему же. Почитать немного на эту тему.
Ну и только не CreateThread, а BeginThread.
-
-
Даж сишники стремаются: _beginthread/ex
А так можно такую штучку замутить
TWork.Add(BeginThread(nil, 0, @TWork.Run, TWork.Create, 0, PCardinal(0)^)); // ))
-
>Dimka Maslov © (24.03.16 20:15) [17]
А может все же почитать? Или самому по граблям интереснее? :)
Есть новые 
Нет новых [134434 +28][b:0][p:0.001]