¿Por qué Themes.pas filtra el singleton TThemeServices cuando se vincula a un archivo DLL

Question

Actualización: Los cambios para introducir estilos VCL en XE2 han eliminado la pérdida de memoria. Así que supongo que fue involuntario después de todo.

---

Me encontré con una fuga de memoria VCL hoy, en Themes.pas. Solo ocurre para las DLL. El código de unidad de finalización es tan así:

finalization 
    if not IsLibrary then 
    InternalServices.Free; 

InternalServices es un producto único que se crea en la demanda cuando se llama a la función ThemeServices. Muchas DLL no tienen UI, por lo que nunca crees este singleton. Sin embargo, tengo un complemento COM para Excel que da como resultado esta manifestación de fugas.

La fuga no me molesta particularmente porque esta DLL nunca se carga y descarga repetidamente del mismo proceso. Y sé cómo podría arreglar la fuga usando la variable global ThemeServicesClass.

Mi pregunta, sin embargo, es preguntar si alguien puede explicar por qué este código es la forma en que es. Parece bastante deliberadamente codificado de esta manera. Por mi vida no puedo encontrar una explicación para esta fuga intencional.

Answer 1

Una explicación es que la sección de finalización de la unidad se ejecuta mientras el cerradura del cargador OS está activo. Durante ese tiempo, existen restricciones significativas sobre lo que se permite hacer un archivo DLL sin poner en riesgo el interbloqueo.

Answer 2

Nos encontramos con este mismo problema también. Esto es lo que estamos haciendo actualmente para prevenir la fuga en nuestros proyectos:

1. en la DLL .dpr archivo de añadir temas a la sección de usos.

2. añadir lo siguiente al limpiar la fuga en el cierre:

   procedure DLLEntryProc(EntryCode: integer); 
   begin 
       case EntryCode of 
       DLL_PROCESS_DETACH: 
       begin 
       ThemeServices.Free; 
       end; 
       DLL_PROCESS_ATTACH: 
       begin 
       end; 
       DLL_THREAD_ATTACH: 
       begin 
       end; 
       DLL_THREAD_DETACH: 
       begin 
       end; 
       end; 
   end; 
   
   begin 
       {$IFDEF DEBUG} 
       ReportMemoryLeaksOnShutdown := True; 
       {$ENDIF} 
       DllProc := @DLLEntryProc; 
   end. 
   

Answer 3

En la misma idea de que debe haber una buena razón para dejar que escape (Indy fugas de un par de cosas a propósito así, o al menos lo que solía) prefiero ignorarlo, así:

{$I FastMM4Options.inc} 
... 
{$IFDEF EnableMemoryLeakReporting} 
    if IsLibrary then// ThemeServices is leaked when created in a DLL. 
    RegisterExpectedMemoryLeak(ThemeServices); 
{$ENDIF}