après la mise à niveau, gdb ne sera pas attaché au processus

63

Je viens tout juste de passer de 10.04 à 11.04 et gdb ne me permet plus de m'attacher aux processus. Je reçois l'erreur

.

Attaching to process 10144 Could not attach to process. If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf ptrace: Operation not permitted.

Comment puis-je résoudre ce problème pour pouvoir déboguer à nouveau sans sudo?

    
posée Andrew Redd 10.05.2011 - 00:52
la source

2 réponses

98

Dans Maverick Meerkat (10.10), Ubuntu a introduit un correctif pour interdire le traçage de processus non enfants par des utilisateurs non root - c'est-à-dire. seul un processus parent d'un autre processus peut le rechercher pour les utilisateurs normaux, tandis que root peut toujours récupérer tous les processus. C’est pourquoi vous pouvez utiliser gdb pour attacher via sudo.

Vous pouvez désactiver temporairement cette restriction (et revenir à l'ancien comportement permettant à votre utilisateur de ptrace (gdb) l'un de ses autres processus) en effectuant:

echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

Pour lui permettre de manière permanente éditer /etc/sysctl.d/10-ptrace.conf et changer la ligne:

kernel.yama.ptrace_scope = 1

à lire

kernel.yama.ptrace_scope = 0

Pour en savoir plus sur les raisons de cette modification, consultez le wiki Ubuntu     

réponse donnée alexmurray 10.05.2011 - 04:08
la source
2

Si vous préférez laisser /proc/sys/kernel/yama/ptrace_scope défini sur sa valeur par défaut, 1 , vous pouvez envisager d'utiliser cette solution pour exécuter le programme que vous souhaitez déboguer. Vous pouvez ensuite afficher le débogueur en appuyant simplement sur gdb . Par exemple, pour déboguer le programme (ennuyeux) ^C , procédez comme suit:

$ gdb -q sleep -ex 'run 60'

Voici un exemple complet.

$ gdb -q sleep -ex 'run 60'
Reading symbols from sleep...(no debugging symbols found)...done.
Starting program: /bin/sleep 60
^C
Program received signal SIGINT, Interrupt.
0x00007ffff7ad5d60 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:81
81      ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) backtrace
#0  0x00007ffff7ad5d60 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:81
#1  0x0000000000403cd7 in ?? ()
#2  0x0000000000403b88 in ?? ()
#3  0x00000000004016c9 in ?? ()
#4  0x00007ffff7a35ec5 in __libc_start_main (main=0x401540, argc=2, argv=0x7fffffffea08, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe9f8) at libc-start.c:287
#5  0x00000000004017d5 in ?? ()
(gdb) continue
Continuing.
[Inferior 1 (process 3531) exited normally]
(gdb) quit

Étant donné que sleep 60 a été compilé (sans surprise) sans informations de débogage, la trace ci-dessus contient un minimum d'informations.

    
réponse donnée mpb 24.06.2014 - 01:17
la source

Lire d'autres questions sur les étiquettes