1

Après avoir fini de coder les parties difficiles de mon jeu, j'ai trouvé quelques bugs de gestion de la mémoire. Objects est un NSMutableArray contenant une classe personnalisée.Mon code fuit et fonctionne, ou ne fuit pas et ne se bloque pas. Cela ne semble pas être un problème d'autorelease

- (void) spawnObjects 
{ 
    for (int index = 0; index < INITIAL_OBJECTS; index++) 
    { 
     [objects addObject:[[[MatchObject alloc] initWithImageNameID:(index % 3)] autorelease]]; 
     [[objects objectAtIndex:index] setPosition:[GameLayer randomPoint]]; 
    } 

    ... 
} 

J'utilise plus tard cette fonction.

- (void) checkAllSprites 
{ 

    NSMutableArray *spritesToDelete = [NSMutableArray array]; 
    for (int index = 0; index < [points count] - 1; index ++) 
    { 
     for (MatchObject *planetLike in objects) 
     { 
      CGPoint point1 = [[points objectAtIndex:index] CGPointValue]; 
      CGPoint point2 = [[points objectAtIndex:index+1] CGPointValue]; 
      if ([GameLayer lineIntersectsCircle:point1 :point2 :[planetLike position] :16.0f]) 
      { 

       ParticleSystem *planetDeath = [ParticlePlanetDeath node]; 
       planetDeath.texture = [[TextureMgr sharedTextureMgr] addImage:@"fire.pvr"]; 
       planetDeath.position = [planetLike position]; 
       [self addChild:planetDeath z:0 tag:2]; 

       [spritesToDelete addObject:planetLike]; 

       [self removeChild:planetLike cleanup:YES]; 

      } 

     } 
    } 
    [objects removeObjectsInArray:spritesToDelete]; 
    [spritesToDelete removeAllObjects]; 

} 

Si je n'autorelease dans la première fonction, l'application fonctionne bien. Si c'est le cas, j'essaie d'accéder à un objet désalloué ([position MatchObject]).

Qu'est-ce qui ne va pas ?!

+0

Pouvez-vous afficher le code pour addChild et removeChild? –

Répondre

1

Il semble que vous référencez la mémoire libérée. Lorsque vous libérez réellement la mémoire, elle se bloque car votre programme se réfère à de la mémoire libérée. Lorsque vous ne le relâchez pas avec autorelease, cela fonctionne parce que même s'il y a une fuite de mémoire, le système ne le remarque pas car l'objet n'est pas réellement libéré, donc la référence ne cause pas de problème.

Alors, sortez la loupe et regarder par-dessus votre code à nouveau, et commencer à utiliser le débogueur ... avoir du plaisir :)

+0

Merci, a trouvé le problème dans la fonction chipmunk. – user162400

+1

la fonction chipmunk? –

+0

Chipmunk est une bibliothèque de physique 2D qui est fournie avec Cocos2d-iPhone, que l'OP utilise. – adurdin

0

Y a-t-il une chance que vous fassiez quelque chose dans la méthode "removeChild" qui finit par libérer l'objet? Il ne semble pas y avoir de problème avec le code que vous avez posté ...

+0

removeChild décrémente le nombre de retenues, addChild l'incrémente. Serait-ce un problème? – user162400

+0

comment? afficher le code. Affiche aussi le code pour créer un tableau d'objets. –

1

Juste une supposition sauvage:

Je suppose addChild est retenue l'objet et removeChild libère l'objet.

Mais que se passe-t-il lorsque removeChild ne trouve pas l'objet (c'est-à-dire s'il ne s'agit pas d'un enfant)? Est-ce qu'il libère l'objet aussi dans ce cas? (ce qui ne devrait pas être le cas)

0

Vous devez libérer automatiquement la première fonction, car il s'agit d'une fonction non-init, et vous appelez un init.

A la fin de la première fonction, l'objet est toujours valide, puisque vous l'avez ajouté au tableau qui a provoqué une retenue. Entre la première fonction appelée et la seconde appelée, quelqu'un relâche l'objet, ce qui explique pourquoi l'accès à l'objet est bloqué.

Placez un point d'arrêt dans la première fonction, le dealloc de l'objet et la deuxième fonction, pour voir qui le libère avant le second appel.