• # Pense à...

    Posté par  (site web personnel) . Évalué à 3.

    faire un blog et un memtest ou baisser ton overclocking.

    • [^] # Re: Pense à...

      Posté par  (site web personnel) . Évalué à 1.

      J'ai pensé à la mémoire mais y'a quand meme un truc bizarre...

      J'ai compilé le svn de kopete une bonne dizaine de fois cette semaine et j'ai toujours eu le meme bug, au démarrage.

      Si ma mémoire était corrompu, je vois mal comment une compilation pourrait donner toujours le meme executable avec le meme bug, ca devrait être aléatoire , nan?

      • [^] # Re: Pense à...

        Posté par  (site web personnel) . Évalué à 0.

        Depuis quand la compilation donne un résultat aléatoire ?

        "La première sécurité est la liberté"

        • [^] # Re: Pense à...

          Posté par  (site web personnel) . Évalué à 2.

          Si j'ai un probleme de mémoire, je vois pas comment ca pourrait produire la meme erreur à chaque fois... La mémoire n'est pas utilisé de la meme facon entre deux compilations... C'est ca que je veux dire...

          • [^] # Re: Pense à...

            Posté par  . Évalué à 0.

            La memoire (celle de la stack hein, pas celle du tas, les variables, les pointeurs, mais pas ce sur quoi pointent les pointeurs) est allouée de manière statique à la compilation, ca depend pas de la compilation.
            Par contre une fois le binaire chargé il y a une translation effetuée sur ces adresses memoires virtuelles en addresses physiques, c'est a dire que si tu boot juste en console sans rien de lancé et que tu lance ton prog, il finira surment autre part en memoire que si tu as chargé un X avec un wm. Par contre j'ai remarqué de maniere empirique que si tu relance un programme que tu viens de lancer, il a tendance a etre replacé exactement au meme endroit (plus ou moins un systeme de cache?).

            Tout ca pour dire, un memtest ca coute rien, mais ca donnera ptete pas grand chose...
            T'as regardé du coté des libs? elles ont exactement toutes les memes versions et compilées avec les meme flags et tout et tout?

        • [^] # Re: Pense à...

          Posté par  (site web personnel) . Évalué à 2.

          Si le memtest ne donne rien (mémoire ok), le cpu peut être en cause (défectueux ou en limite d'overclocking, si overclocké)... j'expérimentais le même problème de bugs de calculs très alléatoires (en faisant une boucle de md5sum sur un même fichier, j'obtenais 50 fois le bon résultat, mais 1 fois de temps en temps, une somme erronée). Alors que je pensais mon overclocking stable car jamais aucun freeze et pas de problème de température, mais en fait c'était bien ça. J'intuite que ça se passe au niveau du cache du CPU.
          Dans monc cas, ça se mettait très bien en évidence en utilisant burnMMX :

          burnBX and burnMMX are essentially very intense RAM testers
          also take an optional parameter indicating the RAM size to

          A = 2 kB E = 32 kB I = 512 kB M = 8 MB
          B = 4 F = 64 J = 1 MB N = 16
          C = 8 G = 128 K = 2 O = 32
          D = 16 H = 256 L = 4 P = 64

          Laisser tourner quelques heures la commande suivante
          (elle ne rend la main que si une erreur est détéctée, time indiquera au bout de combien de temps ça a planté)

          time burnMMX L || echo $?

          (L pour des échanges sur 4 Mo, histoire de tester tout le cache du CPU, plus les échanges avec la mémoire).


          Ah, puis dans mon cas, j'ai stabilisé complétement mon cpu en lui mettant juste 0.05V de plus.

  • # Pourquoi poster si c'est pas un bug ?

    Posté par  (site web personnel) . Évalué à 3.

    Tu as mis un commentaire disant que ca marche et donc que tu fermes le bug.
    Si ca marche pas dans tout les cas c'est qu'il y a un bug et il aurait été utile de le localiser.
    Tu considères qu'il n'y a donc pas de bug et tu viens ensuite en parler ici comme d'un bug, faut savoir...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.