Rapport de crash en C pour Linux

Question

Suite à cette question :
Bonne bibliothèque de rapports d'accidents en C#

Existe-t-il une bibliothèque comme CrashRpt.dll qui fait la même chose sous Linux ?Autrement dit, générer un rapport d'échec comprenant un core dump et tout environnement nécessaire et en informer le développeur ?

Modifier:Cela semble être un double de cette question

Answer 1

Voir Obtenir automatiquement des traces de pile sur les systèmes Unix sur Stack Overflow.

Answer 2

Compilez votre code avec les symboles de débogage, entrez coredumpsize illimité dans votre shell et vous obtiendrez un coredump dans le même dossier que le binaire.Utilisez gdb/ddd - ouvrez d'abord le programme, puis ouvrez le core dump.Tu peux vérifier ce pour plus d'informations.

Answer 3

@Ionut
Cela gère la génération du core dump, mais ne gère pas la notification au développeur lorsque d'autres utilisateurs ont eu des plantages.

Answer 4

Nathan, dans quelles circonstances dans un segment à base non nulle ?Je n'ai jamais vu cela se produire au cours de mes 5 années de développement d'applications Linux.

Merci.

Answer 5

@Martin

Je fais de la validation architecturale pour x86, donc je suis très familier avec l'architecture fournie par le processeur, mais très peufamilier avec la façon dont il est utilisé.C'est sur cela que j'ai basé mon commentaire.Si on peut compter sur CR2 pour donner la bonne réponse, alors j’ai tort.

Answer 6

Nathan, je n'insistais pas sur le fait que tu avais tort ;Je disais juste que d'après mon expérience (limitée) avec Linux, la base de segments est toujours nulle.C'est peut-être une bonne question à poser...

Answer 7

Note:il y a deux registres intéressants dans un x86 crash dû à une erreur de segmentation.

La première, PEI, spécifie l'adresse de code à laquelle l'exception s'est produite.Dans la réponse de RichQ, il utilise addr2line pour afficher la ligne source qui correspond à l'adresse du crash.Mais l'EIP peut être invalide ;si vous appelez un pointeur de fonction nul, cela peut être 0x00000000, et si vous corrompez votre pile d'appels, le retour peut insérer n'importe quelle valeur aléatoire dans EIP.

La deuxième, CR2, spécifie l'adresse de données qui a provoqué l'erreur de segmentation.Dans l'exemple de RichQ, il configure i comme pointeur nul, puis y accède.Dans ce cas, CR2 serait 0x00000000.Mais si vous changez :

int j = *i

à:

int j = i[2];

Ensuite, vous essayez d'accéder à l'adresse 0x00000008, et c'est ce que l'on retrouverait dans CR2.