po aktualizacji gdb nie dołącza się do procesu

Niedawno zaktualizowałem z 10.04 do 11.04, a gdb nie pozwoli mi już na dołączanie się do procesów. Pojawia się błąd

Dołączanie do procesu 10144 Nie można dołączyć do procesu. Jeśli identyfikator użytkownika jest zgodny z identyfikatorem procesu docelowego, sprawdź ustawienie / proc / sys / kernel / yama / ptrace_scope lub spróbuj ponownie jako użytkownik root. Aby uzyskać więcej informacji, zobacz /etc/sysctl.d/10-ptrace.conf ptrace: Operacja niedozwolona.

Jak to naprawić, aby móc ponownie debugować bez sudo?

— Andrew Redd
źródło

Odpowiedzi:

105

W Maverick Meerkat (10.10) Ubuntu wprowadził łatę, która uniemożliwia śledzenie procesów innych niż potomne przez użytkowników innych niż root - tj. tylko proces, który jest rodzicem innego procesu, może śledzić go dla zwykłych użytkowników - podczas gdy root może nadal śledzić każdy proces. Dlatego wciąż możesz używać gdb do łączenia przez sudo.

Możesz tymczasowo wyłączyć to ograniczenie (i przywrócić stare zachowanie, pozwalając użytkownikowi na śledzenie (gdb) dowolnego innego procesu) poprzez:

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

Aby na stałe zezwolić na edycję /etc/sysctl.d/10-ptrace.conf i zmienić linię:

kernel.yama.ptrace_scope = 1

Czytać

kernel.yama.ptrace_scope = 0

Aby dowiedzieć się, dlaczego wprowadzono tę zmianę, zobacz wiki Ubuntu

— alexmurray
źródło

Dzięki. Dodałem tymczasowe do polecenia w moim pliku bin użytkownika, dzięki czemu mogę go włączyć i wyłączyć, działa świetnie.

— Andrew Redd,

Edytuję /etc/sysctl.d/10-ptrace.confplik. działa dla mnie idealnie. :)

— soroosh,

Jeśli wprowadziłeś jakieś zmiany w plikach w /etc/sysctl.d, możesz zastosować je automatycznie za pomocą „sudo service procps restart”

— frankster

@alexmurray - Twoja pomocna odpowiedź powinna również pamiętać, że aby zmiany zaczęły obowiązywać, konieczne jest ponowne uruchomienie /etc/sysctl.d. Dla mnie ponowne uruchomienie systemu było wystarczające, ale mogło to być przesada - patrz komentarz frankster powyżej. Po ponownym uruchomieniu wartość z /etc/sysctl.djest kopiowana do /proc/sys/kernel/yama/ptrace_scope. (Również w moim przypadku nie mogłem bezpośrednio edytować ptrace_scope, nawet z sudo.)

— Andy Thomas

Ponowne uruchomienie nie jest potrzebne. Po prostu uruchom: sysctl -paby zastosować zmiany z /etc/sysctl.confi /etc/sysctl.d/*. Dla tej konkretnej zmiany w Ubuntu 15.04 Vivid plik to/etc/sysctl.d/10-ptrace.conf

— Mircea Vutcovici,

Jeśli wolisz pozostawić /proc/sys/kernel/yama/ptrace_scopeustawioną domyślną wartość 1, wówczas obejściem tego problemu może gdbbyć uruchomienie programu, który chcesz debugować. Następnie możesz uruchomić debuger, naciskając ^C. Na przykład, aby debugować program (nudny) sleep 60, wykonaj następujące czynności:

$ gdb -q sleep -ex 'run 60'

Oto kompletny przykład.

$ 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

Ponieważ /bin/sleepzostał (co nie dziwi) skompilowany bez debugowania informacji, powyższy ślad zawiera minimalne informacje.

— mpb
źródło

Nie przywiązałeś się , zacząłeś . Jest zupełnie inaczej, ponieważ w tym przypadku gdbjest bezpośrednim rodzicem debugowanego i ma wszelkie prawo do debugowania go nawet przy pomocy ptrace_scope==1. To nie zadziałałoby, gdybyś zamiast tego przywiązał się , tj. Zrobił coś w stylusleep 60& gdb -ex "attach $!"

— Ruslan

Proponowany przez Ruslana (kontr?) Przykład sleep 60& gdb -ex "attach $!"nie polega na „używaniu gdb do uruchamiania programu”, a zatem nie jest obaleniem mojego obejścia. Przykładem Ruslana jest użycie powłoki do pierwszego uruchomienia, sleepa następnie uruchomienia gdb. Moje obejście działa , na tym mi zależy. Nie wiem ani nie obchodzi mnie, czy tak gdbnaprawdę przywiązuje się do dziecka. Zależy mi na tym, aby móc debugować dziecko. Moje obejście tego dokonuje. Niemniej jednak dla jasności przeredagowałem swoją odpowiedź.

— mpb