addr2line sur le module du noyau

Je suis en train de déboguer les modules du noyau. Je le soupçonne d'avoir il y a quelques fuites de mémoire. Pour le vérifier j'ai préparé à bâtir avec permis de fuite de Mémoire de débogage pour le noyau et les modules. Et j'ai eu un avertissement de que:

[11839.429168] slab error in verify_redzone_free(): cache `size-64': memory outside object was overwritten
[11839.438659] [<c005575c>] (unwind_backtrace+0x0/0x164) from [<c0116ca0>] (kfree+0x278/0x4d8)
[11839.447357] [<c0116ca0>] (kfree+0x278/0x4d8) from [<bf083f48>] (some_function+0x18/0x1c [my_module])
[11839.457214] [<bf083f48>] (some_function+0x18/0x1c [my_module]) from [<bf08762c>] (some_function+0x174/0x718 [my_module])
[11839.470184] [<bf08762c>] (some_function+0x174/0x718 [my_module]) from [<bf0a56b8>] (some_function+0x12c/0x16c [my_module])
[11839.483917] [<bf0a56b8>] (some_function+0x12c/0x16c [my_module]) from [<bf085790>] (some_function+0x8/0x10 [my_module])
[11839.496368] [<bf085790>] (some_function+0x8/0x10 [my_module]) from [<bf07b74c>] (some_function+0x358/0x6d4 [my_module])
[11839.507476] [<bf07b74c>] (some_function+0x358/0x6d4 [my_module]) from [<c00a60f8>] (worker_thread+0x1e8/0x284)
[11839.517211] [<c00a60f8>] (worker_thread+0x1e8/0x284) from [<c00a9edc>] (kthread+0x78/0x80)
[11839.525543] [<c00a9edc>] (kthread+0x78/0x80) from [<c004f8fc>] (kernel_thread_exit+0x0/0x8)

Il n'y a pas de problème pour traduire les adresses des points de noyau:

$ addr2line -f -e vmlinux.kmeml c0116ca0
verify_redzone_free
/[...]/kernel/mm/slab.c:2922

Mais je ne peux pas le faire si les adresses sont de mon_module:

$ addr2line -f -e vmlinux.kmeml bf0a56b8
??
??:0

J'ai essayé avec le fichier du module:

$ addr2line -f -e my_module.ko bf0a56b8
??
??:0

Comment puis-je traduire cela répond aux fichiers et aux numéros de ligne?

InformationsquelleAutor Adam | 2011-05-27
  1. 28

    Je suppose que le module est construit avec les informations de débogage inclus. Si oui, vous pouvez utiliser gdb ou objdump pour trouver la source de fichier et la ligne à chaque adresse appartient à. Quelque chose comme ceci:

    $ gdb "$(modinfo -n my_module)"
(gdb) list *(some_function+0x12c)

    Gdb vais maintenant le nom du fichier source et la ligne en elle.

    Vous pouvez aussi faire quelque chose de similaire avec objdump, mais il est un peu plus difficile. Tout d'abord, démonter le module:

    objdump -dSlr my_module.ko > my_module.disasm

    Lorsqu'il est appelé avec -S option, objdump comprendra les lignes du code source dans la liste le cas échéant.

    Vous pouvez maintenant faire défiler la liste vers le bas pour le code de some_function, trouver les instructions à l'offset 0x12c depuis le début de la fonction. La ligne de source sera indiquée au-dessus d'elle.

    EDIT:

    Après de nombreuses expériences, j'ai trouvé que, bien que addr2line peut en effet être utilisée pour les modules du noyau, eu-addr2line (un outil similaire de elfutils) semble être plus fiable. C'est, parfois addr2line de sortie incorrect lignes de source mais eu-add2line fait les choses.

    À utiliser eu-addr2line, on peut avoir besoin d'installer libdw et libebl bibliothèques si elles ne sont pas déjà installé avec elfutils.

    L'utilisation est similaire à celle de addr2line:

    eu-addr2line -f -e <path_to_the_module> -j <section_name> <offset_in_section>

    Si les informations de débogage pour un module du noyau est stocké dans un fichier distinct (c'est souvent le cas pour les noyaux fournis par les grandes distributions Linux), le chemin d'accès à ce fichier doivent être utilisés comme <path_to_the_module>.

    • Une note de côté. Si vous travaillez sur x86 et votre noyau Linux 2.6.31 ou plus récent, vous pouvez trouver un plus léger KEDR système (kedr.berlios.de) permet de vérifier vos modules pour les fuites de mémoire. Contrairement intégré dans le noyau des installations comme Kmemleak, KEDR ne nécessite pas de reconstruire le noyau. Il devrait être assez facile à configurer et à utiliser.
    InformationsquelleAutor Eugene
  2. 8

    Vous avez en effet besoin de courir addr2line sur votre module de noyau et pas le noyau, mais il y a un twist -

    le module de noyau de fichier utilise par des adresses relatives, l'écrasement de l'adresse que vous avez est en fait composé de:

    décalage module intérieur + le module de chargement de l'adresse de mémoire.

    Donc ce que vous devez faire est de trouver le kernel module de chargement de l'adresse de la mémoire est d'abord en faisant cat /proc/modules, de trouver à ce module qui appartient l'adresse, au cas où vous ne savez pas, il faut soustraire le module de chargement de l'adresse de l'écrasement de l'adresse et de l'alimentation qui est à addr2line

    bonne chance

    InformationsquelleAutor gby
  3. -3

    Peut-être que vous devriez utiliser le paramètre-g pour compiler le module.

    InformationsquelleAutor paykoob