[Lazarus] Memory leak in TThread class

[Andrew Brunner]

On Tue, Oct 5, 2010 at 10:26 AM, waldo kitty <wkitty42 at windstream.net> wrote:
> if it has no chance to run, it should not allocate the memory...
>
> if it allocates the memory during a create-suspended, it should un-allocate
> that memory during a destroy-suspended...
>
> in other words, it should not matter if the thread is suspended or not... if
> it allocates memory during creation it should deallocate that memory during
> destruction...
>

This is what I feel *should* happen as well.  Unfortunately, depending
on OS and Version I think that is where the problem comes into play.
I seem to recall that destroying a thread object in Delphi under Win98
or NT4 would generate kernel exceptions (ages ago).  The kernel is
responsible for deleting the actual thread object that an FPC thread
object represents.

The problem probably lands with the notion that somewhere the FPC
thread is calling ENDTHREAD or something of the like while the thread
is in a created but suspended state (which may be entirely different
than create and then suspend manually depending on OS).

Since FPC has their hands limited options with respect to threads that
the operating system maintains then the only real solution that may
prove useful is a work-a-round.  To get past this issue in the past I
have used a ResumeThread Call.  The execute method codes to check the
terminated so that was essentially bypassed inside itself before it
loops and a call.

I RARELY use MyThread.Free FOR EXACTLY this reason.  I typically set
the FreeOnTerminate option to True and handle things in the blind.

So if  coded properly, this issue can be avoided all-together.  And I
really don't think this is a bug per say, but a challenge that
requires skill to avoid.