después de la actualización, gdb no se adjuntará al proceso

67

Recientemente actualicé de 10.04 a 11.04 y gdb ya no me permite adjuntarme a los procesos. Recibo el error

Adjuntar al proceso 10144 No se pudo adjuntar al proceso. Si su uid coincide con el uid del proceso de destino, verifique la configuración de / proc / sys / kernel / yama / ptrace_scope, o intente nuevamente como usuario root. Para obtener más detalles, consulte /etc/sysctl.d/10-ptrace.conf ptrace: Operación no permitida.

¿Cómo soluciono esto para que pueda depurar nuevamente sin sudo?

11.04 sudo debug debugging Andrew Redd
fuente

Respuestas:

107

En Maverick Meerkat (10.10) Ubuntu introdujo un parche para no permitir el seguimiento de procesos no secundarios por parte de usuarios no root, es decir. solo un proceso que es padre de otro proceso puede trazarlo para usuarios normales, mientras que la raíz aún puede trazar cada proceso. Por lo tanto, ¿por qué puede usar gdb para adjuntar a través de sudo todavía?

Puede deshabilitar temporalmente esta restricción (y volver al comportamiento anterior que permite a su usuario rastrear (gdb) cualquiera de sus otros procesos) haciendo lo siguiente:

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

Para permitirlo permanentemente, edite /etc/sysctl.d/10-ptrace.conf y cambie la línea:

kernel.yama.ptrace_scope = 1

Leer

kernel.yama.ptrace_scope = 0

Para obtener algunos antecedentes sobre por qué se realizó este cambio, consulte el wiki de Ubuntu

alexmurray
fuente
44
Gracias. Agregué el temporal a un comando en mi archivo bin de usuario para poder encenderlo y apagarlo. Funciona muy bien.
Andrew Redd
Edito el /etc/sysctl.d/10-ptrace.confarchivo. Funciona perfectamente para mí. :)
soroosh
8
Si ha realizado algunas modificaciones en archivos en /etc/sysctl.d, puede aplicarlas automáticamente con "reinicio de
procps de
@alexmurray: su respuesta útil también debe tener en cuenta que es necesario reiniciar de algún tipo para que los cambios surtan /etc/sysctl.defecto. Para mí, un reinicio del sistema fue suficiente, pero puede haber sido excesivo; vea el comentario de frankster arriba. Después del reinicio, el valor de /etc/sysctl.dse copia en /proc/sys/kernel/yama/ptrace_scope. (Además, en mi caso no pude editar ptrace_scope directamente, incluso con sudo.)
Andy Thomas
No es necesario reiniciar. Simplemente ejecute: sysctl -ppara aplicar cambios desde /etc/sysctl.confy /etc/sysctl.d/*. Para este cambio específico, en Ubuntu 15.04 Vivid, el archivo es/etc/sysctl.d/10-ptrace.conf
Mircea Vutcovici
3

Si prefiere dejar /proc/sys/kernel/yama/ptrace_scopeestablecido el valor predeterminado de 1, entonces, como solución alternativa, podría considerar usar gdbpara ejecutar el programa que desea depurar. Luego puede abrir el depurador simplemente presionando ^C. Por ejemplo, para depurar el programa (aburrido) sleep 60, haga lo siguiente:

$ gdb -q sleep -ex 'run 60'

Aquí hay un ejemplo completo.

$ 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

Como /bin/sleepse compiló (como era de esperar) sin información de depuración, la traza anterior contiene información mínima.

mpb
fuente
2
No te uniste , lo empezaste . Es bastante diferente, ya que en este caso gdbes el padre directo del depurado y tiene todo el derecho de depurarlo incluso con ptrace_scope==1. No funcionaría si en su lugar se adjunta , es decir, hizo algo comosleep 60& gdb -ex "attach $!"
Ruslan
El ejemplo propuesto por Ruslan (¿contador?) sleep 60& gdb -ex "attach $!"No es "usar gdb para ejecutar el programa" y, por lo tanto, no es una refutación de mi trabajo. El ejemplo de Ruslan es usar el shell para ejecutar primero sleepy luego ejecutar gdb. Mi solución funciona , que es lo que me importa. No sé, ni me importa realmente, si gdbrealmente se está uniendo a su hijo. Me importa poder depurar al niño. Mi solución lo logra. Sin embargo, he reformulado mi respuesta para mayor claridad.
mpb