Print

[Kryvich]

I have memory leaks when close my application, when an user stopped the program with ThreadPool.CancelAll
The code:

Code: [Select]

procedure MyWorker(const task: IOmniTask);
begin
  Form1.Log(Format('Task started ID=%d Name=%s', [task.UniqueID, task.Name]));
  Sleep(2000);
end;

procedure TForm1.btnCreateClick(Sender: TObject);
var
  i: integer;
begin
  GlobalOmniThreadPool.MaxExecuting := 5;
  for i := 0 to 100 do begin
    CreateTask(MyWorker, 'Test task #' + IntToStr(i))
      .Unobserved
      .Schedule;
  end;
  Log('Tasks are sheduled...');
end;

procedure TForm1.btnCancelClick(Sender: TObject);
begin
  GlobalOmniThreadPool.CancelAll;
end;

In Test.dpr:

Code: [Select]

  ReportMemoryLeaksOnShutdown := DebugHook <> 0;

Press Create, Cancel, and close the window.

[Kryvich]

I've found out that the problem doesn't concern neither ThreadPool.CancelAll nor ThreadPool.MaxExecuting. The leaks appear only when more than 80 tasks are sheduled. If 79 tasks are sheduled - the leaks disappear.

[Primoz Gabrijelcic]

Yes, there's a weird problem with Windows message queues which I cannot pin down. Usually it helps if you call Application.ProcessMessages between two CreateTasks.

[Kryvich]

Perhaps, this issue concerns the order of threads termination? I've changed the code a little:

Code: [Select]

procedure MyWorker(const task: IOmniTask);
begin
  Form1.Log(Format('Task started ID=%d Name=%s', [task.UniqueID, task.Name]));
  Sleep(3000);
end;

procedure TForm1.btnCreateClick(Sender: TObject);
var
  i: integer;
begin
  GlobalOmniThreadPool.MaxExecuting := 1;
  for i := 1 to 51 do begin
    CreateTask(MyWorker, 'Test task #' + IntToStr(i))
      .MonitorWith(OmniEventMonitor)
      .Schedule;
  end;
  Log('Tasks are sheduled...');
end;

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
  GlobalOmniThreadPool.CancelAll;
end;

Press Create button, then after a queuing of the tasks close the window.

If we create less than 51 tasks - there are no leaks. But if we create 51 tasks - there will be a leak of one instance of the TOmniContainerWindowsMessageObserver class. Tested on Windows 7 x64 and Windows XP.

Event Log fragment:

Code: [Select]

...
Debug Output: <<<Execute thread 02327650:5052 Process Test2.exe
Thread Exit: Thread ID: 5052. Process Test2.exe
Debug Output: Thread 02327650:4212 completed request :3 Process Test2.exe
Debug Output: Destroying :3 Process Test2.exe
Debug Output: Asy_TerminateWorkItem thread 02327650:4212 Process Test2.exe
Debug Output: Destroying thread 02327650:4212 Process Test2.exe
...

Is it normal that the worker's thread is terminated before a task thread is destroyed?

[Primoz Gabrijelcic]

Are you doing anything task-related in OnCloseQuery or OnClose?

[Kryvich]

Sorry, my assumption was mistaken.
And no, nothing special in OnCloseQuery and OnClose. Sample application is attached.

[Kryvich]

I give up. I'll write a replacement for the TOmniThreadPool, lightweight, without using of interfaces.

[Primoz Gabrijelcic]

I'm sorry I can't take a look at that immediately. I'll fix it as soon as possible.

[Kryvich]

No problem at all, Primoz! I have created already my thread pool. It works great with the OtlTaskControls, though not so rapid as your TOmniThreadPool. Have tested on the multi-threaded web spider application - no issues.

[Primoz Gabrijelcic]

Create 1 + Cancel + Close: Works fine. (At least with the today's fix to OtlEventMonitor.pas.)
Create 2 + Cancel + Close: Lost memory. I'll look into it.

[Kryvich]

Yes, Create1 creates 50 tasks - no leaks, while Create2 creates 51 tasks and produces one leak. I couldn't understand why. A multithreaded code is really hard to debug.

[Kryvich]

The problem is resolved! See http://www.thedelphigeek.com/2011/12/how-to-find-missing-release.html for more details.