dopo l'aggiornamento gdb non si collegherà al processo

Ho appena aggiornato da 10.04 a 11.04 e gdb non mi permetterà più di collegarmi ai processi, ricevo l'errore

Collegamento al processo 10144 Impossibile collegarsi al processo. Se il tuo uid corrisponde a quello del processo target, controlla l'impostazione di / proc / sys / kernel / yama / ptrace_scope o riprova come utente root. Per maggiori dettagli, consultare /etc/sysctl.d/10-ptrace.conf ptrace: operazione non consentita.

Come posso risolvere questo problema in modo da poter eseguire nuovamente il debug senza sudo?

— Andrew Redd
fonte

Risposte:

107

In Maverick Meerkat (10.10) Ubuntu ha introdotto una patch per impedire la rintracciabilità dei processi non secondari da parte di utenti non root - ad es. solo un processo che è genitore di un altro processo può rintracciarlo per gli utenti normali, mentre root può ancora rintracciare ogni processo. Ecco perché puoi usare gdb per collegarti tramite sudo still.

È possibile disabilitare temporaneamente questa restrizione (e ripristinare il vecchio comportamento che consente all'utente di individuare (gdb) qualsiasi altro processo) effettuando:

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

Per permetterlo permanentemente modificare /etc/sysctl.d/10-ptrace.conf e cambiare la riga:

kernel.yama.ptrace_scope = 1

Leggere

kernel.yama.ptrace_scope = 0

Per alcuni retroscena sul perché questa modifica è stata apportata, consultare la wiki di Ubuntu

— alexmurray
fonte

Grazie. Ho aggiunto il temporaneo a un comando nel mio file bin dell'utente in modo da poterlo accendere e spegnere funziona alla grande.

— Andrew Redd,

Modifica /etc/sysctl.d/10-ptrace.conffile. Funziona perfettamente per me. :)

— soroosh,

Se hai apportato alcune modifiche ai file in /etc/sysctl.d, puoi applicarle automaticamente con "sudo service procps restart"

— frankster

@alexmurray - La tua risposta utile dovrebbe anche tenere presente che è necessario un riavvio di qualche tipo /etc/sysctl.dper rendere effettive le modifiche . Per me, un riavvio del sistema è stato sufficiente, ma potrebbe essere stato eccessivo - vedi il commento di Frankster sopra. Dopo il riavvio, il valore da /etc/sysctl.dviene copiato in /proc/sys/kernel/yama/ptrace_scope. (Inoltre, nel mio caso non ho potuto modificare direttamente ptrace_scope, anche con sudo.)

— Andy Thomas,

Non è necessario il riavvio. Esegui: sysctl -pper applicare le modifiche da /etc/sysctl.confe /etc/sysctl.d/*. Per questo specifico cambiamento, in Ubuntu 15.04 Vivid, il file è/etc/sysctl.d/10-ptrace.conf

— Mircea Vutcovici,

Se si preferisce lasciare /proc/sys/kernel/yama/ptrace_scopeimpostato il valore predefinito di 1, come soluzione alternativa si potrebbe prendere in considerazione l'utilizzo gdbper eseguire il programma di cui si desidera eseguire il debug. È quindi possibile visualizzare il debugger semplicemente premendo ^C. Ad esempio, per eseguire il debug al programma (noioso) sleep 60, attenere alla seguente procedura:

$ gdb -q sleep -ex 'run 60'

Ecco un esempio 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

Poiché è /bin/sleepstato (non sorprendentemente) compilato senza informazioni di debug, il backtrace sopra contiene informazioni minime.

— MPB
fonte

Non hai attaccato , l'hai iniziato . È abbastanza diverso, poiché in questo caso gdbè il genitore diretto del debuggee e ha tutto il diritto di eseguire il debug anche con ptrace_scope==1. Non avrebbe funzionato se invece avessi attaccato , cioè fatto qualcosa del generesleep 60& gdb -ex "attach $!"

— Ruslan il

L'esempio proposto (contro?) Di Ruslan sleep 60& gdb -ex "attach $!"non sta "usando gdb per eseguire il programma", e quindi non è una confutazione del mio workraound. L'esempio di Ruslan sta usando la shell per prima eseguire sleepe poi eseguire gdb. La mia soluzione alternativa funziona , ed è quello che mi interessa. Non so, né mi interessa davvero, se si gdbsta effettivamente attaccando al figlio. Mi interessa poter eseguire il debug del bambino. La mia soluzione è quella. Tuttavia, ho riformulato la mia risposta per chiarezza.

— mpb,