2010-10-13 4 views
3

J'ai créé une petite application multi-thread et j'essaye de la convertir pour utiliser OmniThreadLibrary. J'utilise le Virtualtreeview pour afficher un journal et le statut/résultats. Le journal de Vst a seulement deux colonnes et l'enregistrement contient juste deux champs de chaîne (extrêmement simple, aucun objet dans l'enregistrement). En utilisant un projet DEMO fourni avec OTL (pool de threads n ° 11), j'ai changé le projet pour utiliser un VirtualTreeview au lieu de la listbox. Quand je "Run Task" de la démo il n'y a pas de fuite de mémoire, mais si je lance "Run Task" plus d'une fois une fuite de mémoire se produira. Une fuite de mémoire se produira si je exécute une tâche plus d'une fois. Si je n'utilise pas du tout VirtualTreeView, aucune fuite de mémoire ne se produit à aucun moment. Juste quand j'utilise le VST et quand une tâche est exécutée plus d'une fois.Fuite de mémoire en utilisant VirtualTreeview et OTL

J'utilise l'événement FreeNode et effacer les cordes, et même essayé d'utiliser Finaliser ...

exemple:

procedure TFormMain.vstLogFreeNode(Sender: TBaseVirtualTree; 
    Node: PVirtualNode); 
var 
    LogData: PTreeLogData; 
begin 
    LogData:=Sender.GetNodeData(Node); 

    if Assigned(LogData) then begin 
    LogData^.Msgtype := ''; 
    LogData^.Msg := ''; 
    end; 
    //Finalize(LogData^); 

end; 

pourquoi dois-je obtenir une fuite de mémoire lorsqu'une tâche est exécutée plus une fois que? Delphi 2010 avec FastMM4 dernier VirtualTreeview et OTL

+3

Créez un petit programme qui présente ce comportement et publiez-le sur le forum OTL (http://otl.17slon.com/forum). Je suis toujours là pour aider. – gabr

+0

J'allais poster sur votre forum, mais j'étais à peu près sûr que c'était un problème avec la Virtual Treeview, et comme il s'est avéré que le problème venait du VTreeview. Btw, merci pour OTL – Logman

Répondre

10

L'événement NodeFree est uniquement appelé . Validé nœuds, validé signifie généralement Nœuds qui sont affichés une ou plusieurs fois (lorsque l'événement GetText a été appelé). See Memory Leaks when using the Virtual TreeView Component

éditer: vous pouvez confirmer en vérifiant votre nombre de nœuds et en comptant le nombre de fois que l'événement NodeFree est appelé.

+0

vous avez raison, si vous mettez ce qui suit après avoir créé le nœud, les fuites de mémoire ont disparu: "vst1.ValidateNode (aNode, False);" J'ai utilisé ValidateNode lorsque j'ai mis à jour des nœuds dans un vst auparavant, mais je ne l'ai jamais vu utilisé lorsque vous créez le nœud ... pas dans une démo et un tutoriel. Merci. – Logman

4

Je ne sais pas pourquoi ce qui se passe précisément, mais je sais comment vous pouvez savoir: activer la FullDebugMode de FastMM. (Pour cela, vous devez télécharger la version complète de FastMM à partir de SourceForge.) Activez l'option qui vous donne un rapport de fuite de mémoire dans un fichier et assurez-vous que le projet génère un fichier de carte détaillé. Une fois que vous avez cette configuration, au lieu d'une simple fenêtre contextuelle, FastMM vous donnera un rapport de fuite de mémoire très détaillé, avec des traces de pile. Cela devrait vous aider à affiner ce qui se passe.

1

Comme Mason l'a dit, FastMM4 est votre ami ici. Vous pouvez jeter un oeil à cette session CodeRage 2: Fighting Memory Leaks for Dummies. Il montre principalement comment utiliser FastMM pour empêcher/détecter les fuites de mémoire dans Delphi. Était pour D2007 mais toujours pertinent. En ce qui concerne les raisons pour lesquelles l'exécution double ne fuit pas mais ne s'exécute pas une seule fois, c'est principalement dû à la création et au stockage d'un objet dans un champ/variable sans vérifier si elle a été affectée. Construire comme ceci:

TSomething 
FMyObject: TMyObject; 
[..] 

TSomething.Destroy; 
begin 
    FMyObject.Free; 
end; 
[...] 

//somewhere in code: 
FMyObject := TMyObject.Create; //leaks the previous FMyObject 

évidemment pas aussi simple et probablement caché dans certains setters ou par une sorte de liste/conteneur ... Ici, je suppose ajouter à la VirtualTreeview sans vérifier ...