Bonjour, Le 17233ième jour après Epoch, Olivier écrivait:
> Pardonnez-moi si mes questions semblent idiotes mais: Pas de questions idiotes, seules les réponsent peuvent l'être :-p Pardonne moi, donc, si mes réponses sont idiotes... > 1. À quoi sert exactement un paquet <paquet>-dbgsym ? Doit-on installer > <paquet> et <paquet>-dbgsym ou <paquet>-dbgsym à la place de <paquet> > ? C'est un paquet qui va contenir des infos de débug, des symboles donc. Le paquet s'installe à la place de l'autre, et contient des binaires un peu (voire beaucoup) plus gros, à cause des infos de debug. En général, les programmes sont compilés avec et sans les infos de débug, ou alors juste avec puis sont "strippés" (man strip). Cela donne deux versions des objets, l'un avec et l'autre sans les infos de debug. > 2. Quel rapport entre <paquet>-dbgsym et la production de fichier > coredump ? Avec la production du coredump, rien, mais par contre pour l'analyse de ce coredump, avoir les infos de débug est utile. Tu peux voir le nom des variables en clair plutôt que les adresses hexa, tu vois la pile sous forme de nom de fonctions et non sous forme d'adresses... > 3. Plus généralement, dans mon imaginaire "un fichier coredump est la > condition nécessaire et suffisante pour qu'un développeur (ie pas un > mainteneur) puisse analyser un plantage". Est-ce plutôt exact sinon qu'est > ce qui le serait d'avantage ? Ce n'est ni nécessaire, ni suffisant, mais ça peut être super pratique. Le coredump (illustré des infos de debug) est un instantané pris au moment du plantage, avec lequel tu peux voir les variables, la pile, etc... Mais tu ne vois pas par exemple les conditions initiales, le chemin du programme pour en arriver là, etc... J'espère avoir éclairé un peu ta lanterne. -- Do not sleep in a eucalyptus tree tonight.