Ouarf ouarf cOuntO non non c’est une appli sous Solaris (enfin ça tourne aussi sous Linux et Windows/Cygwin).
En fait j’ai un plantage et lorsque le debugger reprend la main il est aux fraises… ça sent le débordement mémoire… c’est la galèèèèrre je suis sûr que le pb est bien antérieur au plantage (classique)… code de daube ! ça me gonfle, je passe mon temps à remettre de l’ordre dans cette appli… pffff… putain de bordel, quand je vois comment c’est écrit :casstet: rhhhaaallll
[quote]l’implantation est cohérente avec la MAP alors qu’après avoir déroulé du code les adresses d’implantation changent…[/quote]c’est un .exe de plus de 64 ko sous (win)DOS ??
c’est normaaaallll
maintenant, hein, je sais pas : c’est quoi le problem ?
J’ai encore dit n’importe quoi. Les adresses indiquées dans la table des symboles (MAP) décrivent bien les adresses d’implantation en RAM, enfin dans l’espace adressable.
J’ai un peu plus affiné mon pb et j’ai pu constater qu’après le chargement de mon application (sans démarrage) l’implantation est cohérente avec la MAP alors qu’après avoir déroulé du code les adresses d’implantation changent… :casstet: putain d’appli de merde codée à la mord moi le noeud… rhaaaalll j’ai un gros bug de merde :mad: et ça va être coton à trouver ça… c’est bien la première fois que je vois ça :casstet:
zepostman> merci de vouloir m’aider ;). Pour info le debugger GDB s’utilise aussi avec une sur-couche appelée DDD qui est un peu plus ergonomique que la couche de base de GDB ; mais merci pour le lien.
tu peux changer tes options de compilation pour genere un fichier .map, qui, comme son nom l’indique va te donner toutes les adresses et le contenue de tes segments !
