Quels sont les numéros de déchirure/rsp segfault et comment les utiliser

Question

Lorsque mes plantages d'application linux, il produit une ligne dans les journaux quelque chose comme:

segfault à 0.000.000 rip 00003f32a823 rsp 000123ade323 erreur 4

Quels sont ces adresses rip et rsp? comment les utiliser pour identifier le problème? correspondent-ils à quelque chose dans les sorties "objdump" ou "readelf"? sont-ils utiles si mon programme retire ses symboles (dans un fichier séparé, qui peut être utilisé avec gdb)

Answer 1

Le pointeur de déchirure vous indique l'instruction à l'origine du plantage. Vous devez le rechercher dans un fichier de carte.

Dans le fichier de carte, vous aurez une liste de fonctions et leur adresse de départ. Lorsque vous chargez l'application, elle est chargée dans une adresse de base. Le pointeur de déchirure - l'adresse de base vous donne l'adresse du fichier de carte. Si vous recherchez ensuite une fonction qui commence à une adresse légèrement plus basse que votre pointeur et qui est suivie dans la liste par une fonction avec une adresse plus élevée, vous avez localisé la fonction qui s'est écrasée. De là, vous devez essayer d'identifier ce qui s'est mal passé dans votre code. Ce n'est pas très amusant mais au moins, cela vous donne un point de départ. Edit: Le bit "segfault at" vous dit, je parie, que vous avez déréférencé un pointeur NULL. Le rsp est le pointeur de la pile en cours. Hélas ce n'est probablement pas tout ce qui est utile. Avec un vidage de la mémoire, vous serez peut-être en mesure de déterminer avec plus de précision où vous en seriez dans la fonction, mais cela peut être très difficile de travailler, exactement là où vous êtes dans une construction optimisée

Answer 2

erreur aussi. Quand j'ai vu:

probe.out[28503]: segfault at 0000000000000180 rip 00000000004450c0 rsp 00007fff4d508178 error 4 

sonde.out est une application qui utilise libavformat (ffmpeg). Je l'ai démonté.

objdump -d probe.out 

La déchirure est où l'instruction se déroulera:

00000000004450c0 <ff_rtp_queued_packet_time>: 
    4450c0:  48 8b 97 80 01 00 00 mov 0x180(%rdi),%rdx 
    44d25d:  e8 5e 7e ff ff   callq 4450c0 <ff_rtp_queued_packet_time> 

enfin, j'ai trouvé l'application écrasé dans la fonction ff_rtp_queued_packet_time

PS. parfois l'adresse ne correspond pas exactement, mais elle est presque là.