c00000005 ACCESS_VIOLATION when exiting application while thread is running

Question

c00000005 ACCESS_VIOLATION caused when closing the Form (exiting application) while the following thread is running (this is just an EXAMPLE, to illustrate the problem):

type
  Twtf = class(TThread)
  protected
    procedure Execute; override;
  end;

procedure Twtf.Execute;
const
  hopefully_big_enough_to_trigger_problem = 100000000;
var
  A: array of Integer;
  I: Integer;
begin
  SetLength(A, hopefully_big_enough_to_trigger_problem);
  while not Terminated do begin
    for I := Low(A) to High(A) do
      A[I] := 0;
  end;
end;

var
  wtf: Twtf;

procedure TForm1.Button4Click(Sender: TObject);
begin
  wtf := Twtf.Create;
  wtf.FreeOnTerminate := True;
end;

What is happening according to the Local Variables debug window is that A is now (), namely Length(A) is 0. Obviously this is why accessing A[I] causes problems, but note that I did not manually do anything to A.

How do I stop this error from showing (does not necessarily have to be prevented from happening)? The application is closing, the thread should just die... QUIETLY. Which actually happens for smaller arrays, but with a sufficiently large one 1 or 2 out of every 3 attempts results in the problem (if run with debugging it is shown always; i.e., this always happens, but is sometimes simply hidden).

The following does not help:

destructor TForm1.Destroy;
begin
  wtf.terminate;
  inherited;
end;

Only doing TerminateThread(wtf.Handle, 0); in the destructor instead solves (hides) the problem. But surely there is a more graceful way?

Answer 1

Once you start self-destroying thread, you seriously limit your ability to manage it and perform required cleanup and waiting. They are convenient as fire-and-forget threads that need to run rather small tasks where task can be safely interrupted (killed) at any moment.

If the task requires cleanup, then you should not use self-destroying threads.

Besides the AV that happens during application shutdown, there are other issues with your code.

---

Following code is not a proper way to initialize self-destroying thread:

wtf := Twtf.Create;
wtf.FreeOnTerminate := True;

In above code thread will start running immediately after construction, and it is possible (although not very likely) that thread will complete its job, before you can set FreeOnTerminate flag to true and that would create memory leak.

Proper way is to create thread in suspended mode, then set FreeOnTerminate and then start a thread:

wtf := Twtf.Create(True);
wtf.FreeOnTerminate := True;
wtf.Start;

Another way to do that is overriding TThread.Create and setting FreeOnTerminate flag there.

---

Next issue is that after you start self-destroying thread, you should never ever access its reference. So you can never call wtf.Terminate, nor call TerminateThread(wtf.Handle, 0); because at that point thread could already been destroyed and wtf will be dangling reference pointing to non-existing instance.

Because you cannot call wtf.Terminate the while not Terminated loop is also useless, unless you will be constructing other instances of that thread class which you will manually manage.

---

There are many ways to solve your problem, but which one you will choose depends on actual job the thread is doing and how many of such threads you need running and whether you can freely interrupt (terminate) them or you need to wait for them to finish.

If you can safely interrupt whatever thread is doing and showing AV is your only problem, then you can just wrap the code inside Execute method with try...except and eat up the exception.

The best option is to use manually managed thread, which you will create once and destroy when form is closing. In that case while not Terminated loop makes sense as it will allow thread to be interrupted on application shutdown. You can also call wtf.Terminate earlier in the application shutdown process (for instance in OnClose, or OnCloseQuery to give thread more time to check Terminated flag.

 procedure TForm1.Button4Click(Sender: TObject);
 begin
   wtf := Twtf.Create;
 end;

destructor TForm1.Destroy;
begin
  // calling Free will terminate thread and wait for it
  wtf.Free; 
  inherited;
end;

Of course, there are other options for managing threads regardless of whether they are self-destroying ones or manually managed, but it is impossible to list them all, especially when your particular use case is not clear. But all those require some additional mechanisms for signaling to thread that it needs to stop its work or application that there are threads still running.

Depending on the Delphi version you are using, you might also want to look at TTask as running and handling tasks will be easier than handling threads and threads used for running tasks are automatically managed by RTL.

---

If you really, really, really insist on using self-destroying threads and just want to kill everything as fast as possible once uses closes the application, then you can use TerminateProcess. Be aware, that any abrupt termination of either threads or process by calling TerminateThread, ExitProcess, TerminateProcess can cause issues if your application uses DLLs or shares memory. See: TerminateProcess function and Terminating a Process

To do that you can add following destructor in your main form:

destructor TForm1.Destroy;
begin
  inherited;
  TerminateProcess(GetCurrentProcess, 0);
end;

---

Additional reading:

How to wait that all anonymous thread are terminated before closing the app?

Can I call TerminateThread from a VCL thread?

Answer 2

To reiterate:

This was an example crafted to illustrate what happens when a thread loop is accessing a dynamic array when the application is terminated (regardless of whatever graceful shutdown mechanisms, the thread may be within the loop at that point in time, and blocking the application while waiting a possibly long while for it to finish or get to a if Terminated check is not optimal for obvious reasons).

The problem is caused by the application freeing the array's memory before it frees the thread, WHILE the thread is working on the array (the array is a variable belonging to the thread); e.g., with a sufficiently large multidimensional A: array of array of Integer, it is actually possible to see A[500000] freed to () while A[400000] is still fine.

The solution is so simple as to be trivial:

Twtf = class(TThread)

...

var
  wtf: Twtf;

...

destructor TForm1.Destroy;
begin
  // Only Form in the Application, otherwise add Application.Terminated check?
  if wtf <> nil then
    with wtf do
      if not Finished then
        Suspend;
  inherited;
end;

This eliminates the race condition between the thread working on its array and the application freeing that array.

Note that the thread will NOT call its destructor, so resources (if necessary) should be freed manually.

All of the above is irrespective of FreeOnTerminate.

EDIT: Added Finished check

EDIT: Alternative to deprecated Suspend: SuspendThread(Handle);