FastMM rapports fuite de mémoire pour la variable de fil d'enregistrement

Question

FastMM signale une fuite de mémoire (UnicodeString) pour l'extrait de code suivant qui utilise une variable de fil d'enregistrement avec une chaîne:

program Project10; 

{$APPTYPE CONSOLE} 

{$R *.res} 

uses 
    FastMM4, 
    System.SysUtils; 

type 
    TContext = record 
    Value : String; 
    end; 

threadvar 
    Context : TContext; 

begin 
Context.Value := 'asdfsdfasfdsa'; 
end. 

Est-ce une vraie fuite de mémoire ou est nettoyage des variables de thread juste après que FastMM vérifie les fuites de mémoire?

Encore plus important: comment est-ce que je peux supprimer ces "fuites de mémoire" signalées car elles encombrent d'autres fuites de mémoire qui pourraient être trouvées?

Answer 1

C'est une vraie fuite. Les variables locales de thread ne sont pas finalisées lorsqu'elles sont hors de portée. Étant donné que votre enregistrement contient un champ géré, le champ chaîne, la mémoire allouée par tas associée à cette chaîne est divulguée si l'enregistrement n'est pas finalisé.

Les documentation appelle cette explicitement:

variables dynamiques qui sont habituellement gérées par le compilateur (longues chaînes, des chaînes larges, des tableaux dynamiques, des variantes, et interfaces) peuvent être déclarées avec threadvar, mais le compilateur ne libère pas automatiquement la mémoire allouée par tas créée par chaque thread d'exécution. Si vous utilisez ces types de données dans des variables de thread, il est de votre responsabilité de disposer de leur mémoire à partir du thread, avant que le thread se termine.

Si vous souhaitez colmater la fuite, vous devrez finaliser la variable à la fin de la portée. C'est-à-dire que le thread se termine.

Finalize(Context); 

Notez que vous devez exécuter ce code du fil qui possède la variable puisque, de toute évidence, que ce fil a accès.

Si vous souhaitez supprimer le signalement de ces fuites, appelez RegisterExpectedMemoryLeak.

Si vous ne pouvez pas exécuter de code lorsque les threads se terminent, il peut être préférable d'éviter l'allocation de tas et d'utiliser un tableau de caractères de longueur fixe. Très probablement que vous répondez à vos besoins.

Il semblerait étrange que vous prétendez ne pas être en mesure d'exécuter du code lorsque les threads se terminent. Si vous ne pouvez pas faire cela, comment pouvez-vous exécuter du code dans le contexte de ces threads. En d'autres termes, pour qu'il y ait une fuite, vous devez avoir exécuté votre code dans ces threads.

Answer 2

Créer un tableau global de TContext, puis stocker l'index de l'élément, qui appartient à votre thread, dans un threadvar.