Generics and Classes on Windows 2000 = OOM

[aehimself 396]

Just now, Vandrovnik said:

New versions of compiler may use new functions in Windows API, that are not present in Windows 2000. So application will start and then complain about missing something (or start and immediatelly die silently).

Spot on, did not think about this. It would be pretty easy to diagnose, though.

[Remy Lebeau 1393]

46 minutes ago, aehimself said:

Theoretical question. Is seems the scope of local variables is the end of the method. So if I have

Procedure TMyThread.Execute;
Var
 tdictkeys: TArray<String>;
Begin
 While Not Terminated Do
  tdictkeys := _privatedict.Keys.ToArray;
End;

...where the amount of items are growing in the dictionary (by an other thread for example, imagining thread safety non-existent for this example), does it mean that the array will keep relocating (without releasing the previous memory area); without a detectable leak but effectively causing OOM?

The TDictionary.Keys property uses a singleton, so no matter how many times you read the Keys property itself, there will only be 1 TKeyCollection object in memory.  However, every time you call ToArray() on that collection, it will allocate a new array in memory and populate it with the current keys.  Dynamic arrays are reference counted, so every assignment to the local tdictkeys variable will decrement the refcount of the old array, freeing it, and increment the refcount of the new array.  When the method exits, the refcount of the last array allocated is decremented, freeing it.

 

If the dictionary is continuously growing in count, then the loop above will allocate larger and larger arrays accordingly, , where a new array is allocated before the previous array is freed.  So yes, that has the potential to cause an OOM error over time, depending on just how large the dictionary actually grows.

46 minutes ago, aehimself said:

Correct me if I'm wrong but a Win32 binary is a Win32 binary. A Win32 compatible OS should be able to run it, no?

At the assembly level, yes.  But if the binary has external dependencies on DLLs/APIs that don't exist on the machine (and modern versions of Delphi's RTL do use APIs that don't exist in Win2K), then the binary will not be loaded by the OS and will not be allowed to run any of its code.

[Fr0sT.Brutal 900]

9 hours ago, Remy Lebeau said:

modern versions of Delphi's RTL do use APIs that don't exist in Win2K

Fortunately we have sources of RTL so some of these issues could be fixed.

[aehimself 396]

So after weeks of attempting to find the guilty code piece I found nothing. Every allocation had a release pair, memory usage was perfectly consistent for close to a month. This combined with the fact that only one machine was affected means that whatever happened, it was not caused by my code (and therefore generics and classes) and was only a coincidence.

And I think I already know what happened.

 

So thanks all for the tips; at least we know that (even if it's unsupported) D10.3 applications are running happily (and correctly) on Windows 2000 too 🙂