David Heffernan

Actually, I am probably misleading you here. OTL needs a message loop which isn't there. I'm sure you can run one but it doesn't come for free in a blank console app. Sorry!

FWIW, the repro could quite readily be expressed as a console app. It's worth learning how to do that because those apps are much simpler to share, being just a single file.

{$POINTERMATH ON} would be preferable, so avoiding the static array type

Calls to ExitProcess or TerminateProcess. My experience however is that guesswork is not much of a basic for solving problems. My experience is that debugging is way more effective. My advice is that you debug your problem. Cutting down to a minimal reproduction is one way to start doing that.

Those are reported as leaks for me. As I said, we need a minimal reproduction.

Leak reporting works fine. I guess your code doesn't have a leak. Throw in a call to GetMem and see how that goes.

Leak reporting works. If you want help, make a minimal reproduction, and post it here.

Nothing has gone wrong with FastMM and memory leak reporting works fine.

Works fine in any context. If you notice though, I supplied a complete program. You only supplied snippets, the latest of which does not compile. Perhaps if you want help finding the bug in your code you could supply a complete but minimal reproduction, just as I did. Then it would be simple for us to find the mistake.

Works fine here. I wrote a version with the threading removed to make it simpler to understand. {$APPTYPE CONSOLE} uses System.SysUtils; function CaptureValue(Value: Integer): TProc; begin Result := procedure begin Writeln(Value); end; end; procedure Main; var i, j: Integer; Procs: TArray<TProc>; begin SetLength(Procs, 10); for i := 0 to 9 do Procs[i] := procedure begin Writeln(i); end; for j := 0 to 9 do Procs[j](); for i := 0 to 9 do Procs[i] := CaptureValue(i); for j := 0 to 9 do Procs[j](); end; begin Main; Readln; end. Output is 10 10 10 10 10 10 10 10 10 10 0 1 2 3 4 5 6 7 8 9

You have captured the variable. But you need to capture the value. Capturing the value is not supported directly so you need to fake that by making a copy of the variable into a new value, one per task. More detail here http://docwiki.embarcadero.com/RADStudio/en/Anonymous_Methods_in_Delphi https://stackoverflow.com/a/24223683/505088

Ugh. Good luck reasoning about the security of such a thing.

You probably need to hook at the other processes. Not easy, and likely to be extremely brittle. Also won't work for any programs that do system menus in a non standard way.

Would be easier for people to help if you could post a minimal repro.

On each iteration, each value is modified. So, during the iteration, just keep track of the smallest value that you have seen to date.

Build the ISO 4217 table into your code and lookup the currency code from the country code.

No, that is the device that measures mileage

No English speaker I know, here in the UK, would say anything other than mileage. This is one of those words whose meaning is now detached from its etymology.

Well, there are plenty of types for which races lead to errors. But how races manifest is not part of what defines them. A race is simply unserialised access to a shared resource. There aren't multiple definitions of this term.

This is the dictionary definition of a race

I don't buy that argument. People are using the software now. And software is never finished. There is always more to be done. So if you wait until it is done, then you never document it. My personal experience, and very strongly felt, is that writing documentation is a key part of finalising and debugging specification. So many times have I experienced this. Only when you write the documentation do you realise some of the issues that users will face. Deal with them before releasing and you don't have to spend as much time in back compat hell. My view is that writing documentation in a timely fashion actually saves time and resources in the long run.

Python documentation is excellent. Likewise C# documentation. And so on. Delphi is an outlier here.

Reading the stdout of the child process is a very easy way to do this.

You followed the instructions for 64 bit compilers, made the necessary change to the code outlined on the page you linked, obtained 64 bit drivers etc?

It's not clear whether you mean 64 bit Windows, or 64 bit iOS or 64 bit Linux.