›

messages garbage avec xcode 3.1

bofybofy Membre
11:03 modifié dans API AppKit #1
Bonjour

Je suis en train de construire une application Cocoa avec Xcode 3.1.
J'ai des tas de messages :
21/08/08 15:32:49 [0x0-0x19019].com.apple.Xcode[198] Xcode(198,0xf0103000) malloc: free_garbage: garbage ptr = 0x322b130, has non-zero refcount = 1

Comment les éliminer, puisqu'ils ne sont pas liés à  mon application ?
Ce n'est pas grave, mais très agaçant !
Merci

Réponses

  • Philippe49Philippe49 Membre
    11:03 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
  • bofybofy Membre
    11:03 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 ?
  • schlumschlum Membre
    11:03 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;

  • ChachaChacha Membre
    11:03 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
  • Philippe49Philippe49 Membre
    11:03 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 ?
  • bofybofy Membre
    11:03 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.
  • Philippe49Philippe49 Membre
    11:03 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.
  • KronosKronos Membre
    11:03 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.

  • Philippe49Philippe49 Membre
    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.
Connectez-vous ou Inscrivez-vous pour répondre.