Journal Adresse de pointeur non initialisé!

Posté par WildChild le 15 avril 2004 à 15:08.

Étiquettes : aucune

avr.

2004

J'avais à faire un petit programme pour un travail d'université. Fonctionnant à merveille sous Linux et SunOS (La correction des travaux se fait sur un serveur Sun) j'ai décidé de tenter le test sous Windows. Malheur!! Le programme plante. En mode debug avec Dev-Cpp je tombe sur quelque chose d'assez drôle. Lors du plantage je regarde mon pointeur qui plante et il est initialisé à... 0xbaadf00d. (Je me suis vite rendu compte que c'était le seul pointeur que j'avais oublié d'initialiser à NULL lors de son allocation.

Quelqu'un a déjà vu d'autres adresses du genre? Sous Visual C++ j'ai le code 0xCDCDCDCD.

# Re: Adresse de pointeur non initialisé!

Posté par . Takhi le 15 avril 2004 à 15:17. Évalué à 1.

Google is mon ami:
http://www.nobugs.org/developer/win32/debug_crt_heap.html(...)

Il semble que cela permette de savoir quel est l'etat d'un pointeur en mode Debug: ( alloué par le systeme, alloué par malloc, liberé par free, liberé par le systeme ...)

http://www.nobugs.org/developer/win32/debug_crt_heap.html#table(...)

BadFood, c'est apres l'invocation de HeapAlloc,
CDCDCD ... c'est apres l'invocation de malloc
- [^] # Re: Adresse de pointeur non initialisé!
  
  Posté par Colin Leroy (site web personnel) le 15 avril 2004 à 15:20. Évalué à 2.
  
  ça s'appelle "Magic-numbers", et les développeurs linux utilisent ça aussi lorsqu'ils allouent des structures. ça permet de savoir qui a débordé où.
  
  Dommage que la glibc ne fasse pas ça...
# Re: Adresse de pointeur non initialisé!

Posté par Pascal le 15 avril 2004 à 15:21. Évalué à 2.

Essaye de lcompiler ton programme sous Linux avec Electric Fence.
Souvent, efence met en valeur des erreurs de pointeurs et d'allocations mémoires bien que le porgramme parait fonctionner normallement.

Personnelement, quand je dévelloppe en C, je linke toujours mes programmes avec Electric Fence. Cela permet de corriger rapidement certaines erreurs.
- [^] # Re: Adresse de pointeur non initialisé!
  
  Posté par Krunch (site web personnel) le 15 avril 2004 à 16:55. Évalué à 1.
  
  Pour le développement d'accord mais libefence(3) (sous Debian) nous dit:
  Since Electric Fence uses at least two virtual memory pages for each of its allocations, it's a terrible
  memory hog. I've sometimes found it necessary to add a swap file using swapon(8) so that the system would
  have enough virtual memory to debug my program. Also, the way we manipulate memory results in various
  cache and translation buffer entries being flushed with each call to malloc or free. The end result is
  that your program will be much slower and use more resources while you are debugging it with Electric
  Fence.
  
  Don't leave libefence.a linked into production software! Use it only for debugging.
  
  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
  - [^] # Re: Adresse de pointeur non initialisé!
    
    Posté par Pascal le 15 avril 2004 à 17:02. Évalué à 1.
    
    Bien sur, Electric Fence ralentit enormement les programmes. Il ne faut certainement pas le laisser sur un programme que l'on utilise. Mais l'utiliser en permanence pour le dévellopement permet de traquer les bugs dès qu'ils sortent.
    Surtout que en général, les bugs causés par les erreurs de pointeurs ou d'allocations mémoires, ne sont difficelement reproductibles (un programmes peut fonctionner plusieurs semaines avant qu'un segmentation fault ne mette la puce à l'oreille) et apparaissent parfois très loin de l'erreur initiale.
    - [^] # Re: Adresse de pointeur non initialisé!
      
      Posté par Krunch (site web personnel) le 15 avril 2004 à 17:34. Évalué à 1.
      
      C'est juste que ton précédent commentaire laissait penser que tu utilisais libefence tout le temps.
      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Re: Adresse de pointeur non initialisé!

Posté par deftones_chris le 15 avril 2004 à 15:24. Évalué à 1.

Sous mainframe IBM (z900 sous VM/CMS), les pointeurs sont initialisés avec des valeurs aux hasard (chose qui ne va pas à l'encontre de la norme ANSI) ou le terme exacte serait que les pointeurs sont initialisés avec des valeurs indéfinies.
- [^] # Re: Adresse de pointeur non initialisé!
  
  Posté par SamG le 15 avril 2004 à 15:36. Évalué à 1.
  
  Moi j'aurais plutôt dit que le pointeur n'est pas initialisé justement.
  Si ce pointeur est créé dans une fonction, le pointeur (qui est une simple variable) va être réservé sur la pile. La valeur par défaut du pointeur va donc dépendre du contenu de la pile.
  - [^] # Re: Adresse de pointeur non initialisé!
    
    Posté par deftones_chris le 15 avril 2004 à 15:58. Évalué à 1.
    
    C'est juste une histoire de terme :)
    Etre initialisé avecune valeur indéfinie ou bien ne pas être initiliasé revient au même :) Le pointeur lors de sa déclaration a une valeur qu'on ne peut déterminer et qui n'est pas constante d'une exécution à l'autre.
# Re: Adresse de pointeur non initialisé!

Posté par Mickaël Sibelle (site web personnel) le 15 avril 2004 à 15:38. Évalué à 3.

Lance ton programme avec valgrind.
C'est une sorte de machine virtuelle...
Elle te dira des trucs sur ta gestion de la mémoire !
# Re: Adresse de pointeur non initialisé!

Posté par TazForEver le 15 avril 2004 à 15:47. Évalué à 2.

la norme devrait exiger qu'un pointeur non initialisé le soit avec la valeur 0xdeadbeef :o
- [^] # Re: Adresse de pointeur non initialisé!
  
  Posté par WildChild le 15 avril 2004 à 16:45. Évalué à 1.
  
  Mais rendu là pourquoi sous Dev-Cpp (Mingw) c'est 0xbaadf00d et sous Visual Studio c'est 0xCDCDCDCD?? Il n'allouent pas la mémoire de la même façon?
  - [^] # Re: Adresse de pointeur non initialisé!
    
    Posté par pas_moi le 15 avril 2004 à 17:04. Évalué à 1.
    
    Tu as lu le premier commentaire?
  - [^] # Re: Adresse de pointeur non initialisé!
    
    Posté par TazForEver le 15 avril 2004 à 18:20. Évalué à 1.
    
    #include <humour.h>
    
    le C ne garantie aucune initialisation : à toi de la faire manuellement. si tu ne le fais pas, ta variable locale (ou ta zone mémoire allouée dynamiquement) comportera tout et n'importe quoi : des zéros, des valeurs bizarres, du texte, bref tout ce qu'on peut trouver en mémoire non-inialisée. c'est un comportement indéfini (UB) ce qui explique qu'en fonction du système et du compilateur tu observes un comportement différent : encore une fois, c'est ta faute, ton bug.
    - [^] # Re: Adresse de pointeur non initialisé!
      
      Posté par WildChild le 15 avril 2004 à 20:23. Évalué à 1.
      
      Non je sais! J'initialise mes pointeurs manuellement habituellement mais là c'était un oubli! Et c'est en déboguant ce qui ne plantait pas sous Linux/SunOS avec Windows que j'ai vu le 0xbaadf00d (Bad Food). Cette adresse n'est surement pas là par hasard! :)
      - [^] # Re: Adresse de pointeur non initialisé!
        
        Posté par TazForEver le 15 avril 2004 à 22:44. Évalué à 1.
        
        tu ferais bien d'utiliser des outils comme electric-fence et d'augmenter tes niveaux de warning à gcc (ou bien utiliser des outils comme lint).
        
        2 règles essentielles :
        - toujours veiller à ce qu'une variable soit initialiser
        - déclarer une variable au plus prêt de son initialisation (merci gcc/C99 qui permet de déclarer les variables partout et pas uniquement en début de bloc)
# Re: Adresse de pointeur non initialisé!

Posté par 0xDEADBEEF le 16 avril 2004 à 08:20. Évalué à 0.

Je pige rien là, c'est quoi ces adresses bizarres dont tu parles ? C'est de l'héxa c'est ça ?

Pffff... Comprend jamais rien moi...

Suivre le flux des commentaires

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