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.