IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

CORBA Discussion :

Compilation TAO / Mfc : Memory Leaks


Sujet :

CORBA

  1. #1
    Futur Membre du Club
    Profil pro
    Inscrit en
    Janvier 2005
    Messages
    10
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2005
    Messages : 10
    Points : 6
    Points
    6
    Par défaut Compilation TAO / Mfc : Memory Leaks
    Bonjour à tous,

    Je souhaite implémenter l'Orb TAO au sein d'une application MFC standard, en utilisant Visual C++ 6.0. L'application semble tourner convenablement, mais cependant, je me suis rendu compte que pas mal de fuites mémoires subsistaient.

    Apres un "nettoyage" méticuleux du code, les fuites étaient encore là, et je me suis appecu qu'il suffisait d'un simple "include" d'un fichier de TAO pour que ces fuites soient présentes, meme si mon code est totalement "vide" ( pas d'instanciation d'objets CORBA, ... ).

    Apres renseignements, j'ai finallement recompilé l'intégralité des librairies avec les parametres ACE_HAS_DLL=1,ACE_HAS_MFC=1 , meme si cela n'a à priori pas grand chose à voir. Et effectivement, cela ne change rien. Toujours mes fuites, peu nombreuses mais bien présentes.

    J'ai remarqué qu'en n'incluant plus mes fichiers TAO dans les headers, mais dans le .Cpp, AVANT le StdAfx, les problèmes ne se posent plus, mais c'est un peu trop contraignant..

    J'utilise ACE version : 5.3a_p11 et TAO version : 1.3a_p11.

    Quelqu'un pourrait m'aider ? :-)

    Si cela vous dit quelque chose, comme cela, voici le TRACE que Visual me sort à la fin de l'execution :

    ---
    Dumping objects ->
    {323} normal block at 0x00B3CCC0, 13 bytes long.
    Data: <TAO_IORTable > 54 41 4F 5F 49 4F 52 54 61 62 6C 65 00
    {322} normal block at 0x00B3CD00, 36 bytes long.
    Data: < 0 > C0 CC B3 00 30 B0 B3 00 CD CD CD CD 00 00 00 00
    {321} normal block at 0x00B3CD50, 13 bytes long.
    Data: <TAO_IORTable > 54 41 4F 5F 49 4F 52 54 61 62 6C 65 00
    {320} normal block at 0x00B3B030, 20 bytes long.
    Data: < O P P` > D8 95 4F 00 50 CD B3 00 90 CD B3 00 A0 50 60 00
    {319} normal block at 0x00B3CD90, 28 bytes long.
    Data: < c` > 90 63 60 00 01 00 00 00 00 00 00 00 00 00 00 00
    {271} normal block at 0x00B39440, 8 bytes long.
    Data: <TAO_POA > 54 41 4F 5F 50 4F 41 00
    {270} normal block at 0x00B39480, 36 bytes long.
    Data: <@ > 40 94 B3 00 10 95 B3 00 CD CD CD CD 00 00 00 00
    {269} normal block at 0x00B394D0, 8 bytes long.
    Data: <TAO_POA > 54 41 4F 5F 50 4F 41 00
    {268} normal block at 0x00B39510, 20 bytes long.
    Data: < O 5 > D8 95 4F 00 D0 94 B3 00 20 9C B3 00 B0 86 35 00
    {267} normal block at 0x00B39C20, 28 bytes long.
    Data: <x 9 > 78 BC 39 00 01 00 00 00 00 00 00 00 00 00 00 00
    {266} normal block at 0x00B26F08, 4096 bytes long.
    Data: < > 80 94 B3 00 00 CD B3 00 CD CD CD CD CD CD CD CD
    {265} normal block at 0x00B381B0, 40 bytes long.
    Data: < o 8r > 08 6F B2 00 02 00 00 00 00 04 00 00 38 72 14 00
    {258} normal block at 0x00B38690, 8 bytes long.
    Data: < > B0 18 B3 00 CD CD CD CD
    {61} normal block at 0x00B31870, 8 bytes long.
    Data: < @ > 90 86 B3 00 B8 40 1B 10
    {60} normal block at 0x00B318B0, 8 bytes long.
    Data: <p @ W > 70 18 B3 00 40 1C 57 00
    {59} normal block at 0x00B31B50, 32 bytes long.
    Data: < lO L > 18 6C 4F 00 D0 4C 14 00 FF FF FF FF 00 00 00 00
    {58} normal block at 0x00B31BA0, 12 bytes long.
    Data: < h-W > 90 86 B3 00 02 00 00 00 68 2D 57 00
    Object dump complete.

    ---

    D'avance, merci infiniement ( ca me bloque bien, cette co... ) !

    Roland TOMCZAK.

  2. #2
    Membre régulier
    Inscrit en
    Septembre 2004
    Messages
    66
    Détails du profil
    Informations forums :
    Inscription : Septembre 2004
    Messages : 66
    Points : 74
    Points
    74
    Par défaut
    Avec un serceur Corba, tout simple , activation d'un objet ..... etc
    sous solaris , j ai des UMR, mais pas de MLK (il semblerait)

    j'instrumente mon executable avec purify, et bien des que je declenche
    la detection des memories leaks , je corre ( en appuyant sur le
    petit robine situe tout en haut)

  3. #3
    Membre régulier
    Inscrit en
    Septembre 2004
    Messages
    66
    Détails du profil
    Informations forums :
    Inscription : Septembre 2004
    Messages : 66
    Points : 74
    Points
    74
    Par défaut
    tu utilises purify pour les MLK ?
    ces MLK apparaissent ou ?

  4. #4
    Futur Membre du Club
    Profil pro
    Inscrit en
    Janvier 2005
    Messages
    10
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2005
    Messages : 10
    Points : 6
    Points
    6
    Par défaut
    Nop, jamaisutilisé Purify.. Je vais en arriver la, si il est dispo dans ma boite.. Je vais me renseigner ! Merci du conseil... !

    Mais si quelqu'un d'autre à une idée je suis toujours preneur )

  5. #5
    Membre régulier
    Inscrit en
    Septembre 2004
    Messages
    66
    Détails du profil
    Informations forums :
    Inscription : Septembre 2004
    Messages : 66
    Points : 74
    Points
    74
    Par défaut
    sous unix Solaris , si tu veux analyser l'etat de la heap ( pour les memories leaks, je te conseille d'utliser la commade pmap)

    (pas nmap pour sniffer le reseau )

    %pmap Numero_process | grep heap
    tu peux faire un petit script qui dumpe les differentes valeurs
    au cours du temps ... pour voir l'evolution

    Surveille ausi le rss de ton process

    MLK = memory leak
    PLK = potential memory leak
    FUM , UMR ( variable non initialise ... )

    purify est un produit Rational
    attention on ne pas 'purifie un objet partage'


Discussions similaires

  1. Réponses: 8
    Dernier message: 28/10/2010, 20h08
  2. [MFC] Thread & memory leaks
    Par Racailloux dans le forum MFC
    Réponses: 7
    Dernier message: 15/03/2005, 12h44
  3. Memory leak en C/C++
    Par Roswell dans le forum Autres éditeurs
    Réponses: 6
    Dernier message: 07/07/2004, 19h41
  4. [MFC] A la chasse au memory leak
    Par Yabo dans le forum MFC
    Réponses: 17
    Dernier message: 27/06/2004, 17h35
  5. Réponses: 7
    Dernier message: 26/02/2004, 09h32

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo