messages garbage avec xcode 3.1

Réponses

• Philippe49 Membre

  août 2008 12:29 modifié #2

  Tu dois avoir le Garbage Collector activé.
  Si tu le désactives, il faut vérifier si tu n'as pas de Leaks-Memory

  2162_.png 33K
• bofy Membre

  août 2008 12:29 modifié #3

  dans 1219395883:

  
  Tu dois avoir le Garbage Collector activé.
  Si tu le désactives, il faut vérifier si tu n'as pas de Leaks-Memory
  

  
  Qu'est-ce que c'est : Leaks-Memory ?
• schlum Membre

  août 2008 12:29 modifié #4

  De la mémoire allouée sur laquelle on n'a plus de contrôle, et qui est donc perdue.
  
  Ex :
  

  NSString *s = [[NSString alloc] initWithString:@&quot;blaba&quot;];<br />s = nil;
  

  
  
• Chacha Membre

  août 2008 12:29 modifié #5

  ll me semble qu'on s'éloigne un peu...
  Le message rencontré ([0x0-0x19019].com.apple.Xcode[198] Xcode(198,0xf0103000) malloc:...) vient  de XCode, pas de ton programme. Ce doit être un bug d'XCode. J'ai le même.
  Modifier le statut GarbageCollector ou pas de ton programme ne devrait rien changer.
  
  Après, "Leaks-Memory", ça veut effectivement dire fuite mémoire, le terme consacré étant "memory leak". Une fuite mémoire est la faute d'un programmeur qui oublie de faire libérer de la mémoire qu'il a allouée. Il existe des outils pour dénicher ce genre d'erreurs.
  
  +
  Chacha
• Philippe49 Membre

  août 2008 12:29 modifié #6

  Personnellement, je n'ai jamais vu ce genre de message en dehors de l'utilisation du GC avec XCode 3.1.
  Maintenant quelle est la raison de ce message
  malloc: free_garbage: garbage ptr = 0x322b130, has non-zero refcount = 1
  Il semble quand même bien que ce soit une question de gestion d'allocation ?
  
• bofy Membre

  août 2008 12:29 modifié #7

  Je me demande si ce n'est pas lié au fait que NSLog ne répond jamais immédiatement, du moins chez moi. C'était pareil avec 3.0.
  
  Ce n'est pas très grave, mais oblige à  des tas d'ajouts de NSlog, qui se perdent dans les garbages.
  
  D'où peut venir le bug de XCode ?
  
  Je vais chercher du côté des sites officiels.
• Philippe49 Membre

  août 2008 12:29 modifié #8

  dans 1219502777:

  
  Je me demande si ce n'est pas lié au fait que NSLog ne répond jamais immédiatement, du moins chez moi. C'était pareil avec 3.0.
  
  Ce n'est pas très grave, mais oblige à  des tas d'ajouts de NSlog, qui se perdent dans les garbages.
  
  D'où peut venir le bug de XCode ?
  

  
  Il vous arrive des trucs bizarres !
  
  Pourquoi pas moi   
  
  Le retard du NSLog, si il n'est pas exagéré , est souvent naturel. Il apparaà®t déjà  dans une simple fonction C pour un printf() : c'est sans doute la Console / Terminal qui traite l'affichage et elle n'a pas la main en priorité dans la distribution des tâches par le système.
• Kronos Membre

  août 2008 12:29 modifié #9

  dans 1219516634:

  
  c'est sans doute la Console / Terminal qui traite l'affichage et elle n'a pas la main en priorité dans la distribution des tâches par le système.
  

  
  
  Je dirais plutôt que cela est dû au buffering. Le système Unix stock dans un buffer les données à  inscrire dans un fichier afin de ne pas faire une infinité de petites écritures. Quand le buffer est plein, les données sont réellement écrite dans le fichier. Or, dans le monde Unix, tout est fichier, y compris la console et le terminal. Donc les écritures dans la console et le terminal ne sont pas synchrones. D'ailleurs, pour pallier à  cette gêne, il existe la commande flush qui permet à  un programmeur de déclancher l'écriture du buffer immédiatement, même s'il n'est pas plein.
  
  
• Philippe49 Membre

  août 2008 août 2008 modifié #10

  Certes, mais le NSLog finissant par un \n, le comportement standard du fprintf() est de demander l'affichage dès que faire se peut, c'est à  dire un flush() immédiat.
  De plus ce n'est pas le programme que l'on a écrit qui rafraà¯chit la fenêtre de la console ou du terminal, tout cela est géré par dessus notre programme. Notre programme n'est qu'un client dans cette situation.