waldo kitty wrote 9 lines
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.
