In that case probably look further down in the list.
If you leak some object, that often leaks other data.
The string, may have been created at that point, but it could then have been assigned to other objects later.
If you try to find this, you have to find where the string is read directly from the field.
From what I see the getter uses UnEscape which creates a new unique string, at a different memory location.
But if anything directly accesses FDataBase/FHostName, then that could hold an to the strings memory and leak it.
-----------------
Actually just looked at it:
There is a bug in UnEscape/ReplaceChar.
I was
not able to construct a simple case where this would end in a leak.
There are however plenty of cases where this could lead to random and/or crashing behaviour.
You need a very good understanding of what "const x:string" does. Which is the opposite of what most people expect.
One thing it does is, to prevent ref-counting.
In ReplaceChar
Result := ReplaceChar(#9, ';', Result);
The value returned by ReplaceChar is assigned to the same variable that is passed in as "Str".
Note also that "Result" variables (for managed types, such as string) are not actually returned, but passed by the caller to the function.
function ReplaceChar(const Source, Target: Char; const Str: string): string;
begin
Result := Str;
So Result and Str in ReplaceChar are the same string (pointing to the same memory).
But then
Result := Str;
modifies Result (decrease the ref count of the old value). And by that it modifies "Str". But Str is const, and therefore you are not allowed to modify it.
And yes this is documented
https://www.freepascal.org/docs-html/ref/refsu67.htmlSee the "side effect" example.
The param is modified via the global var. And in the example it is the global var that points to the same string. Above it is result, that points to the same string...
So there is a bug in zeos.