2010-06-09 3 views
0

J'écris une application iPhone qui essaie de créer une seconde vue lorsque l'utilisateur clique sur un élément dans UITableView. Le code ressemble àComment déboguer des problèmes d'allocation de mémoire?

ReplyToViewController *reply = [[ReplyToViewController alloc] initWithNibName:@"ReplyTo" bundle:nil]; 
reply.delegate = self; 
Message *message = [resultData objectAtIndex:indexPath.row]; 
int dbid = [message.bizid intValue]; 
NSLog(@"dbid=%d",dbid); 

reply.currentMessage = message; 
reply.modalTransitionStyle = UIModalTransitionStyleFlipHorizontal; 
[self presentModalViewController:reply animated:YES]; 

L'objet réponse est créé correctement et la vue est correcte. La dernière ligne du segment de code ci-dessus appelle un code de structure qui appelle éventuellement la méthode viewDidLoad de ReplyToViewController. L'adresse de l'objet réponse dans le code ci-dessus et l'adresse de l'objet dans viewDidLoad ne sont pas identiques.

Une idée d'où vient ce nouvel objet? Comment puis-je déboguer? J'ai également ajouté la méthode suivante dans ReplyToViewController en espérant qu'elle sera appelée et que je peux trouver qui crée ce nouvel objet. Mais cela ne s'arrête pas dans cette méthode.

Toute aide sera grandement appréciée.

- (id) init 
{ 
/* first initialize the base class */ 
    self = [super init]; 
return self; 
} 

// Following gets called from the 1st code segment. 
- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil 
{ 
    if (self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil]) 
{ 
     // Custom initialization 
    } 

    return self; 
} 

- (void)viewDidLoad 
{ 
    [super viewDidLoad]; 
    NSLog(currentMessage.text]; // THIS returns nil and the program fails later in the code. 
} 

Répondre

0

Je suis sûr que cela est sans rapport, mais je figure ceci:

NSLog(currentMessage.text]; 

devrait être ceci:

NSLog(currentMessage.text); 

Aussi, j'ai trouvé que l'analyse (Cmd + Maj + A) mon code aide toujours à localiser les fuites de mémoire potentielles et empêcher l'allocation de mémoire trop zélée.

0

L'explication la plus probable est une erreur de rapport.

Habituellement, lorsque les gens voient une adresse différente pour un objet, c'est parce qu'ils ont utilisé le mauvais descripteur de format dans leurs déclarations de journal.

Une erreur commune est:

NSLog(@"Object address=%i", myObject); // any numerical formatter %d,%f... 

... qui produit un nombre aléatoire. Vous voulez vraiment:

NSLog(@"Object address=%%qX",&myObject); 

... qui renvoie l'adresse en hexadécimal.

Une autre erreur est:

NSLog(@"Object address=%%qX",&[myObject description]); 

... qui renvoie l'adresse de la chaîne de description qui change à chaque fois.

Il y en a d'autres mais vous avez l'idée.

Si vous utilisez des instructions de journal, vérifiez plutôt l'adresse dans le débogueur pour confirmer qu'il s'agit d'un objet différent. Non corrélé, mais je voudrais me débarrasser des méthodes d'initialisation de la classe parce qu'ils ne font rien d'autre que d'appeler le super. Vous pourriez aussi bien laisser le compilateur par défaut au super si vous ne personnalisez pas.

Questions connexes