2009-09-15 7 views
0

Je reçois une fuite et je ne peux pas détecter d'où cela se produit. La trace de la pile ne donne pas toutes les informations après l'ouverture de dyld. Pour quelques fuites, je ne reçois aucune information de trace de pile. Tout ce que je reçois est seulement l'adresse mémoire de l'objet. Est-ce que quelqu'un d'autre fait face au même problème. J'utilise XCode 3.2 sur show léopard.Mémoire fuite dyld dlopen

18 0x103038 
17 0x1033c7 
16 0x1034a1 
15 0x90145f48 
14 dyld dlopen 
13 dyld dyld::link(ImageLoader*, bool, ImageLoader::RPathChain const&) 
12 dyld ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, ImageLoader::RPathChain const&) 
11 dyld ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&) 
10 dyld dyld::libraryLocator(char const*, bool, char const*, ImageLoader::RPathChain const*) 
9 dyld dyld::load(char const*, dyld::LoadContext const&) 
8 dyld dyld::loadPhase0(char const*, dyld::LoadContext const&, std::vector<char const*, std::allocator<char const*> >*) 
7 dyld dyld::loadPhase1(char const*, dyld::LoadContext const&, std::vector<char const*, std::allocator<char const*> >*) 
6 dyld dyld::loadPhase3(char const*, dyld::LoadContext const&, std::vector<char const*, std::allocator<char const*> >*) 
5 dyld dyld::loadPhase4(char const*, dyld::LoadContext const&, std::vector<char const*, std::allocator<char const*> >*) 
4 dyld dyld::loadPhase5(char const*, dyld::LoadContext const&, std::vector<char const*, std::allocator<char const*> >*) 
3 dyld dyld::mkstringf(char const*, ...) 
2 dyld strdup 
1 dyld mallocenter 
+0

Ne sachant pas comment vous avez écrit votre code rend très difficile de vous donner des suggestions. Typiquement, Instruments vous donne un peu plus d'informations sur la fuite, et en combinant cette information avec votre code, il est plus facile de traquer le coupable. – mahboudz

Répondre

0

Je vois un comportement très similaire dans xcode 3.2. La fuite dyld, qui n'apparaissait pas dans xcode 3.1.x, et je ne vois rien d'autre qu'une adresse mémoire pour d'autres fuites. Juste pour prouver que je n'étais pas fou, j'ai instancié plusieurs UILabels en utilisant alloc et je ne les ai pas libérés. Assez sûr, xcode montre UILabel fuit, mais la stacktrace est seulement des adresses de mémoire. Dans 3.1.x, je voyais une pile beaucoup plus significative, complète avec les noms de classe. Est-ce un bug dans le nouveau xcode?