Server side memory leak on connect related to CharSetVers/Collation

[jojastahl]

@AlexPeshkoff, while working on #9014, I noticed the Firebird 6 server process itself growing substantially in private memory alongside the client-side leak. After ruling out auth method and wire encryption (SRP vs Legacy_Auth and WireCrypt=Required vs Disabled all produced within 0.3% of the same rate), the root cause turned out to be a genuine server-side leak: Utf16Collation objects accumulating in defaultMemPool because CharSetVers::destroy never calls Collation::destroy on the collations it owns.

(Un-)Affected versions

Observed in current FB6 builds, i tested on 5e9635a from 4th June.
With FB3 this was not observed. FB4 or FB5 have not been tested - however, the fixed code/class could not be found there.

Root cause

CharSetVers::destroy (src/jrd/CharSetContainer.cpp) calls delete csv without iterating charset_collations[].

Measured impact (release build, 10,000 connects)

	Server private KB (peak delta)	Per-connect
Before fix	+1,425,768 KB (+1.36 GB)	142 KB — monotonic, no drops
After fix	+33 KB (flat oscillation)	n/a — bounded, no trend

The leak appears to self-heal when ~120 s of idle time fires the PluginManager DEFAULT_DELAY and unloads the engine DLL — taking defaultMemPool with it. BUT: Under continuous load this window never opens.

Fix

index b4bfef4e9a..c36647c205 100644
--- a/src/jrd/CharSetContainer.cpp
+++ b/src/jrd/CharSetContainer.cpp
@@ -35,8 +35,14 @@ CharSetVers* CharSetVers::create(thread_db* tdbb, MemoryPool& pool, Cached::Char
 	return FB_NEW_POOL(pool) CharSetVers(csp);
 }

-void CharSetVers::destroy(thread_db*, CharSetVers* csv)
+void CharSetVers::destroy(thread_db* tdbb, CharSetVers* csv)
 {
+	for (auto* col : csv->charset_collations)
+	{
+		if (col)
+			col->destroy(tdbb);
+	}
+
 	delete csv;
 }