после обновления gdb не будет прикрепляться к процессу

Question 1

Используйте sudo mysqld stop, чтобы остановить его как root.

надеюсь, что это помогло.

Question 2

В Maverick Meerkat (10.10) Ubuntu представила патч, чтобы запретить ptracing не-дочерних процессов пользователями без полномочий root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d1]

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

Чтобы окончательно разрешить редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

kernel.yama.ptrace_scope = 1

Чтобы прочитать

kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

Question 3

Question 4

В Maverick Meerkat (10.10) Ubuntu представила патч, чтобы запретить ptracing не-дочерних процессов пользователями без полномочий root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d1] echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

Чтобы окончательно разрешить редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

kernel.yama.ptrace_scope = 1

Чтобы прочитать

kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

Question 5

В Maverick Meerkat (10.10) Ubuntu представила патч, чтобы запретить ptracing не-дочерних процессов пользователями без полномочий root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d1] echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

Чтобы окончательно разрешить редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

kernel.yama.ptrace_scope = 1

Чтобы прочитать

kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

Question 6

В Maverick Meerkat (10.10) Ubuntu представила патч, чтобы запретить ptracing не-дочерних процессов пользователями без полномочий root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d1] echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

Чтобы окончательно разрешить редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

kernel.yama.ptrace_scope = 1

Чтобы прочитать

kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

Question 7

Question 8

В Maverick Meerkat (10.10) Ubuntu представила патч, чтобы запретить ptracing не-дочерних процессов пользователями без полномочий root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d1] echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

Чтобы окончательно разрешить редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

kernel.yama.ptrace_scope = 1

Чтобы прочитать

kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

Question 9

В Maverick Meerkat (10.10) Ubuntu представила патч, чтобы запретить ptracing не-дочерних процессов пользователями без полномочий root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d1] echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

Чтобы окончательно разрешить редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

kernel.yama.ptrace_scope = 1

Чтобы прочитать

kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

Question 10

В Maverick Meerkat (10.10) Ubuntu представил патч, чтобы запретить ptracing не-дочерних процессов пользователями, не являющимися root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d5]

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

Чтобы окончательно разрешить ему редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

  kernel.yama.ptrace_scope = 1

Для чтения

  kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

Question 11

В Maverick Meerkat (10.10) Ubuntu представил патч, чтобы запретить ptracing не-дочерних процессов пользователями, не являющимися root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d5]

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

Чтобы окончательно разрешить ему редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

  kernel.yama.ptrace_scope = 1

Для чтения

  kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

Question 12

В Maverick Meerkat (10.10) Ubuntu представил патч, чтобы запретить ptracing не-дочерних процессов пользователями, не являющимися root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d5]

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

Чтобы окончательно разрешить ему редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

  kernel.yama.ptrace_scope = 1

Для чтения

  kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

Question 13

Question 14

В Maverick Meerkat (10.10) Ubuntu представил патч, чтобы запретить ptracing не-дочерних процессов пользователями, не являющимися root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d5]

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

Чтобы окончательно разрешить ему редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

  kernel.yama.ptrace_scope = 1

Для чтения

  kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

Question 15

Если вы предпочитаете оставить /proc/sys/kernel/yama/ptrace_scope установленным по умолчанию значением 1, то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^C. Например, чтобы отлаживать (скучную) программу sleep 60, выполните следующие действия:

$ gdb -q sleep -ex 'run 60'

Вот полный пример.

$ 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

Поскольку /bin/sleep был (неудивительно), скомпилированный без отладки информации, вышеупомянутая обратная трассировка содержит минимальную информацию.

Question 16

Если вы предпочитаете оставить /proc/sys/kernel/yama/ptrace_scope установленным по умолчанию значением 1, то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^C. Например, чтобы отлаживать (скучную) программу sleep 60, выполните следующие действия:

$ gdb -q sleep -ex 'run 60'

Вот полный пример.

$ 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

Поскольку /bin/sleep был (неудивительно), скомпилированный без отладки информации, вышеупомянутая обратная трассировка содержит минимальную информацию.

Question 17

Если вы предпочитаете оставить /proc/sys/kernel/yama/ptrace_scope установленным по умолчанию значением 1, то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^C. Например, чтобы отлаживать (скучную) программу sleep 60, выполните следующие действия:

$ gdb -q sleep -ex 'run 60'

Вот полный пример.

$ 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

Поскольку /bin/sleep был (неудивительно), скомпилированный без отладки информации, вышеупомянутая обратная трассировка содержит минимальную информацию.

Question 18

Если вы предпочитаете оставить /proc/sys/kernel/yama/ptrace_scope установленным по умолчанию значением 1, то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^C. Например, чтобы отлаживать (скучную) программу sleep 60, выполните следующие действия:

$ gdb -q sleep -ex 'run 60'

Вот полный пример.

$ 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

Поскольку /bin/sleep был (неудивительно), скомпилированный без отладки информации, вышеупомянутая обратная трассировка содержит минимальную информацию.

Question 19

Question 20

Если вы предпочитаете оставить /proc/sys/kernel/yama/ptrace_scope установленным по умолчанию значением 1, то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^C. Например, чтобы отлаживать (скучную) программу sleep 60, выполните следующие действия:

$ gdb -q sleep -ex 'run 60'

Вот полный пример.

$ 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

Поскольку /bin/sleep был (неудивительно), скомпилированный без отладки информации, вышеупомянутая обратная трассировка содержит минимальную информацию.

Question 21

Если вы предпочитаете оставить /proc/sys/kernel/yama/ptrace_scope установленным по умолчанию значением 1, то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^C. Например, чтобы отлаживать (скучную) программу sleep 60, выполните следующие действия:

$ gdb -q sleep -ex 'run 60'

Вот полный пример.

$ 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

Поскольку /bin/sleep был (неудивительно), скомпилированный без отладки информации, вышеупомянутая обратная трассировка содержит минимальную информацию.

Question 22

Если вы предпочитаете оставить / proc / sys / kernel / yama / ptrace_scope установленным по умолчанию значением 1 , то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^ C . Например, чтобы отладить (скучную) программу sleep 60 , выполните следующие действия:

  $ gdb -q sleep -ex 'run 60' [! D5]

  Вот полный пример. 
   $ gdb -q sleep -ex 'run 60' Чтение символов из сна ... (не найдены отладочные символы) ...  сделанный.  Начальная программа: / bin / sleep 60 ^ C Программный сигнал SIGINT, прерывание.  0x00007ffff7ad5d60 в __nanosleep_nocancel () на ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: Нет такого файла или каталога.  (gdb) backtrace # 0 0x00007ffff7ad5d60 в __nanosleep_nocancel () в ../sysdeps/unix/syscall-template.S:81 # 1 0x0000000000403cd7 in ??  () # 2 0x0000000000403b88 in ??  () # 3 0x00000000004016c9 in ??  () # 4 0x00007ffff7a35ec5 в __libc_start_main (main = 0x401540, argc = 2, argv = 0x7fffffffea08, init = & lt; optimized out & gt ;, fini = & lt; optimized out & gt ;, rtld_fini = & lt; optimized out & gt ;, stack_end = 0x7fffffffe9f8) в libc  -start.c: 287 # 5 0x00000000004017d5 in ??  () (gdb) continue Продолжение.  [Inferior 1 (процесс 3531) вышел из строя] (gdb) quit  
  Поскольку  / bin / sleep  был (неудивительно) скомпилирован без отладки информации, вышеупомянутая обратная трассировка содержит  минимальная информация.

Question 23

Если вы предпочитаете оставить / proc / sys / kernel / yama / ptrace_scope установленным по умолчанию значением 1 , то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^ C . Например, чтобы отладить (скучную) программу sleep 60 , выполните следующие действия:

  $ gdb -q sleep -ex 'run 60' [! D5]

  Вот полный пример. 
   $ gdb -q sleep -ex 'run 60' Чтение символов из сна ... (не найдены отладочные символы) ...  сделанный.  Начальная программа: / bin / sleep 60 ^ C Программный сигнал SIGINT, прерывание.  0x00007ffff7ad5d60 в __nanosleep_nocancel () на ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: Нет такого файла или каталога.  (gdb) backtrace # 0 0x00007ffff7ad5d60 в __nanosleep_nocancel () в ../sysdeps/unix/syscall-template.S:81 # 1 0x0000000000403cd7 in ??  () # 2 0x0000000000403b88 in ??  () # 3 0x00000000004016c9 in ??  () # 4 0x00007ffff7a35ec5 в __libc_start_main (main = 0x401540, argc = 2, argv = 0x7fffffffea08, init = & lt; optimized out & gt ;, fini = & lt; optimized out & gt ;, rtld_fini = & lt; optimized out & gt ;, stack_end = 0x7fffffffe9f8) в libc  -start.c: 287 # 5 0x00000000004017d5 in ??  () (gdb) continue Продолжение.  [Inferior 1 (процесс 3531) вышел из строя] (gdb) quit  
  Поскольку  / bin / sleep  был (неудивительно) скомпилирован без отладки информации, вышеупомянутая обратная трассировка содержит  минимальная информация.

Question 24

Если вы предпочитаете оставить / proc / sys / kernel / yama / ptrace_scope установленным по умолчанию значением 1 , то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^ C . Например, чтобы отладить (скучную) программу sleep 60 , выполните следующие действия:

  $ gdb -q sleep -ex 'run 60' [! D5]

  Вот полный пример. 
   $ gdb -q sleep -ex 'run 60' Чтение символов из сна ... (не найдены отладочные символы) ...  сделанный.  Начальная программа: / bin / sleep 60 ^ C Программный сигнал SIGINT, прерывание.  0x00007ffff7ad5d60 в __nanosleep_nocancel () на ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: Нет такого файла или каталога.  (gdb) backtrace # 0 0x00007ffff7ad5d60 в __nanosleep_nocancel () в ../sysdeps/unix/syscall-template.S:81 # 1 0x0000000000403cd7 in ??  () # 2 0x0000000000403b88 in ??  () # 3 0x00000000004016c9 in ??  () # 4 0x00007ffff7a35ec5 в __libc_start_main (main = 0x401540, argc = 2, argv = 0x7fffffffea08, init = & lt; optimized out & gt ;, fini = & lt; optimized out & gt ;, rtld_fini = & lt; optimized out & gt ;, stack_end = 0x7fffffffe9f8) в libc  -start.c: 287 # 5 0x00000000004017d5 in ??  () (gdb) continue Продолжение.  [Inferior 1 (процесс 3531) вышел из строя] (gdb) quit  
  Поскольку  / bin / sleep  был (неудивительно) скомпилирован без отладки информации, вышеупомянутая обратная трассировка содержит  минимальная информация.

Question 25

Question 26

Если вы предпочитаете оставить / proc / sys / kernel / yama / ptrace_scope установленным по умолчанию значением 1 , то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^ C . Например, чтобы отладить (скучную) программу sleep 60 , выполните следующие действия:

  $ gdb -q sleep -ex 'run 60' [! D5]

  Вот полный пример. 
   $ gdb -q sleep -ex 'run 60' Чтение символов из сна ... (не найдены отладочные символы) ...  сделанный.  Начальная программа: / bin / sleep 60 ^ C Программный сигнал SIGINT, прерывание.  0x00007ffff7ad5d60 в __nanosleep_nocancel () на ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: Нет такого файла или каталога.  (gdb) backtrace # 0 0x00007ffff7ad5d60 в __nanosleep_nocancel () в ../sysdeps/unix/syscall-template.S:81 # 1 0x0000000000403cd7 in ??  () # 2 0x0000000000403b88 in ??  () # 3 0x00000000004016c9 in ??  () # 4 0x00007ffff7a35ec5 в __libc_start_main (main = 0x401540, argc = 2, argv = 0x7fffffffea08, init = & lt; optimized out & gt ;, fini = & lt; optimized out & gt ;, rtld_fini = & lt; optimized out & gt ;, stack_end = 0x7fffffffe9f8) в libc  -start.c: 287 # 5 0x00000000004017d5 in ??  () (gdb) continue Продолжение.  [Inferior 1 (процесс 3531) вышел из строя] (gdb) quit  
  Поскольку  / bin / sleep  был (неудивительно) скомпилирован без отладки информации, вышеупомянутая обратная трассировка содержит  минимальная информация.

alexmurray · Accepted Answer · 25 May 2018 в 21:13

В Maverick Meerkat (10.10) Ubuntu представила патч, чтобы запретить ptracing не-дочерних процессов пользователями без полномочий root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d1]

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

Чтобы окончательно разрешить редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

kernel.yama.ptrace_scope = 1

Чтобы прочитать

kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

93

ответ дан alexmurray 25 May 2018 в 21:13

1

Благодарю. Я добавил временную команду в свой файл bin пользователя, чтобы я мог включить ее и выключить, отлично работает. – Andrew Redd 10 May 2011 в 20:08
2

Я редактирую файл /etc/sysctl.d/10-ptrace.conf. он отлично работает для меня. :) – soroosh 20 April 2013 в 19:29
3

Если вы внесли некоторые изменения в файлы в файле /etc/sysctl.d, то вы можете применить их автоматически с перезагрузкой sudo sproo service " – frankster 18 July 2013 в 19:33
4

@alexmurray. В вашем полезном ответе также следует отметить, что для того, чтобы изменения в /etc/sysctl.d стали эффективными, необходим какой-то перезапуск. Для меня перезапуск системы был достаточным, но, возможно, это было излишним - см. Комментарий франкстера выше. После перезапуска значение из /etc/sysctl.d копируется в /proc/sys/kernel/yama/ptrace_scope. (Кроме того, в моем случае я не мог напрямую редактировать ptrace_scope, даже с помощью sudo.) – Andy Thomas 27 March 2015 в 01:04
5

Перезагрузка не требуется. Просто запустите: sysctl -p, чтобы применить изменения с /etc/sysctl.conf и /etc/sysctl.d/*. Для этого конкретного изменения в Ubuntu 15.04 Vivid файл /etc/sysctl.d/10-ptrace.conf – Mircea Vutcovici 11 August 2015 в 17:52

alexmurray · Accepted Answer · 25 July 2018 в 21:58

В Maverick Meerkat (10.10) Ubuntu представила патч, чтобы запретить ptracing не-дочерних процессов пользователями без полномочий root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d1] echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

Чтобы окончательно разрешить редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

kernel.yama.ptrace_scope = 1

Чтобы прочитать

kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

alexmurray · Accepted Answer · 31 July 2018 в 10:28

В Maverick Meerkat (10.10) Ubuntu представила патч, чтобы запретить ptracing не-дочерних процессов пользователями без полномочий root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d1] echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

Чтобы окончательно разрешить редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

kernel.yama.ptrace_scope = 1

Чтобы прочитать

kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

alexmurray · Accepted Answer · 31 July 2018 в 11:29

В Maverick Meerkat (10.10) Ubuntu представила патч, чтобы запретить ptracing не-дочерних процессов пользователями без полномочий root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d1] echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

Чтобы окончательно разрешить редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

kernel.yama.ptrace_scope = 1

Чтобы прочитать

kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

alexmurray · Accepted Answer · 2 August 2018 в 03:32

В Maverick Meerkat (10.10) Ubuntu представила патч, чтобы запретить ptracing не-дочерних процессов пользователями без полномочий root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d1] echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

Чтобы окончательно разрешить редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

kernel.yama.ptrace_scope = 1

Чтобы прочитать

kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

alexmurray · Accepted Answer · 4 August 2018 в 19:30

В Maverick Meerkat (10.10) Ubuntu представила патч, чтобы запретить ptracing не-дочерних процессов пользователями без полномочий root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d1] echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

Чтобы окончательно разрешить редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

kernel.yama.ptrace_scope = 1

Чтобы прочитать

kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

alexmurray · Accepted Answer · 6 August 2018 в 03:39

В Maverick Meerkat (10.10) Ubuntu представил патч, чтобы запретить ptracing не-дочерних процессов пользователями, не являющимися root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d5]

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

Чтобы окончательно разрешить ему редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

  kernel.yama.ptrace_scope = 1

Для чтения

  kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

alexmurray · Accepted Answer · 7 August 2018 в 21:31

В Maverick Meerkat (10.10) Ubuntu представил патч, чтобы запретить ptracing не-дочерних процессов пользователями, не являющимися root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d5]

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

Чтобы окончательно разрешить ему редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

  kernel.yama.ptrace_scope = 1

Для чтения

  kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

alexmurray · Accepted Answer · 10 August 2018 в 09:47

В Maverick Meerkat (10.10) Ubuntu представил патч, чтобы запретить ptracing не-дочерних процессов пользователями, не являющимися root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d5]

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

Чтобы окончательно разрешить ему редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

  kernel.yama.ptrace_scope = 1

Для чтения

  kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

alexmurray · Accepted Answer · 13 August 2018 в 16:02

В Maverick Meerkat (10.10) Ubuntu представил патч, чтобы запретить ptracing не-дочерних процессов пользователями, не являющимися root, т.е. только процесс, который является родителем другого процесса, может использовать его для обычных пользователей, в то время как root все равно может обрабатывать каждый процесс. Следовательно, вы можете использовать gdb для присоединения через sudo.

Вы можете временно отключить это ограничение (и вернуться к старому поведению, позволяющему вашему пользователю выполнять ptrace (gdb) любой из своих других процессов): [ ! d5]

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

Чтобы окончательно разрешить ему редактировать /etc/sysctl.d/10-ptrace.conf и изменить строку:

  kernel.yama.ptrace_scope = 1

Для чтения

  kernel.yama.ptrace_scope = 0

Для некоторого фона о том, почему это изменение было сделано, см. Ubuntu wiki

96

ответ дан alexmurray 13 August 2018 в 16:02

1

Благодарю. Я добавил временную команду в свой файл bin пользователя, чтобы я мог включить ее и выключить, отлично работает. – Andrew Redd 10 May 2011 в 20:08
2

Я редактирую файл /etc/sysctl.d/10-ptrace.conf . он отлично работает для меня. :) – soroosh 20 April 2013 в 19:29
3

Если вы внесли некоторые изменения в файлы в файле /etc/sysctl.d, то вы можете применить их автоматически с перезагрузкой sudo sproo service & quot; – frankster 18 July 2013 в 19:33
4

@alexmurray. В вашем полезном ответе также следует отметить, что для внесения изменений в /etc/sysctl.d необходим какой-либо перезапуск. Для меня перезапуск системы был достаточным, но, возможно, это было излишним - см. Комментарий франкстера выше. После перезапуска значение из /etc/sysctl.d копируется в / proc / sys / kernel / yama / ptrace_scope . (Кроме того, в моем случае я не мог напрямую редактировать ptrace_scope, даже с помощью sudo.) – Andy Thomas 27 March 2015 в 01:04
5

Перезагрузка не требуется. Просто запустите: sysctl -p , чтобы применить изменения из /etc/sysctl.conf и /etc/sysctl.d / * . Для этого конкретного изменения в Ubuntu 15.04 Vivid файл /etc/sysctl.d/10-ptrace.conf – Mircea Vutcovici 11 August 2015 в 17:52

mpb · Answer 11 · 25 May 2018 в 21:13

Если вы предпочитаете оставить /proc/sys/kernel/yama/ptrace_scope установленным по умолчанию значением 1, то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^C. Например, чтобы отлаживать (скучную) программу sleep 60, выполните следующие действия:

$ gdb -q sleep -ex 'run 60'

Вот полный пример.

$ 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

Поскольку /bin/sleep был (неудивительно), скомпилированный без отладки информации, вышеупомянутая обратная трассировка содержит минимальную информацию.

Вы не присоединяете , вы запустили . Это совсем другое, так как в этом случае gdb является прямым родителем debuggee и имеет полное право отлаживать его даже с помощью ptrace_scope==1. Это не сработает, если вы добавили , т. Е. Сделали что-то вроде sleep 60& gdb -ex "attach $!" — Ruslan, 5 January 2016 в 20:27
Предлагаемый (счетчик?) Пример Руслана sleep 60& gdb -ex "attach $!" не «использует gdb для запуска программы» и, следовательно, не является опровержением моего труда. Пример Руслана использует оболочку , чтобы сначала запустить sleep, а затем запустить gdb. Мое обходное решение работает , что меня волнует. Я не знаю и не забочусь о том, действительно ли gdb прикрепляется к своему ребенку. Я забочусь о возможности отладки ребенка. Мое обходное решение завершает это. Тем не менее, я изложил свой ответ для ясности. — mpb, 7 January 2016 в 01:46

mpb · Answer 12 · 25 July 2018 в 21:58

Если вы предпочитаете оставить /proc/sys/kernel/yama/ptrace_scope установленным по умолчанию значением 1, то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^C. Например, чтобы отлаживать (скучную) программу sleep 60, выполните следующие действия:

$ gdb -q sleep -ex 'run 60'

Вот полный пример.

$ 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

Поскольку /bin/sleep был (неудивительно), скомпилированный без отладки информации, вышеупомянутая обратная трассировка содержит минимальную информацию.

Вы не присоединяете , вы запустили . Это совсем другое, так как в этом случае gdb является прямым родителем debuggee и имеет полное право отлаживать его даже с помощью ptrace_scope==1. Это не сработает, если вы добавили , т. Е. Сделали что-то вроде sleep 60& gdb -ex "attach $!" — Ruslan, 5 January 2016 в 20:27
Предлагаемый (счетчик?) Пример Руслана sleep 60& gdb -ex "attach $!" не «использует gdb для запуска программы» и, следовательно, не является опровержением моего труда. Пример Руслана использует оболочку , чтобы сначала запустить sleep, а затем запустить gdb. Мое обходное решение работает , что меня волнует. Я не знаю и не забочусь о том, действительно ли gdb прикрепляется к своему ребенку. Я забочусь о возможности отладки ребенка. Мое обходное решение завершает это. Тем не менее, я изложил свой ответ для ясности. — mpb, 7 January 2016 в 01:46

mpb · Answer 13 · 31 July 2018 в 10:28

Если вы предпочитаете оставить /proc/sys/kernel/yama/ptrace_scope установленным по умолчанию значением 1, то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^C. Например, чтобы отлаживать (скучную) программу sleep 60, выполните следующие действия:

$ gdb -q sleep -ex 'run 60'

Вот полный пример.

$ 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

Поскольку /bin/sleep был (неудивительно), скомпилированный без отладки информации, вышеупомянутая обратная трассировка содержит минимальную информацию.

Вы не присоединяете , вы запустили . Это совсем другое, так как в этом случае gdb является прямым родителем debuggee и имеет полное право отлаживать его даже с помощью ptrace_scope==1. Это не сработает, если вы добавили , т. Е. Сделали что-то вроде sleep 60& gdb -ex "attach $!" — Ruslan, 5 January 2016 в 20:27
Предлагаемый (счетчик?) Пример Руслана sleep 60& gdb -ex "attach $!" не «использует gdb для запуска программы» и, следовательно, не является опровержением моего труда. Пример Руслана использует оболочку , чтобы сначала запустить sleep, а затем запустить gdb. Мое обходное решение работает , что меня волнует. Я не знаю и не забочусь о том, действительно ли gdb прикрепляется к своему ребенку. Я забочусь о возможности отладки ребенка. Мое обходное решение завершает это. Тем не менее, я изложил свой ответ для ясности. — mpb, 7 January 2016 в 01:46

mpb · Answer 14 · 31 July 2018 в 11:29

Если вы предпочитаете оставить /proc/sys/kernel/yama/ptrace_scope установленным по умолчанию значением 1, то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^C. Например, чтобы отлаживать (скучную) программу sleep 60, выполните следующие действия:

$ gdb -q sleep -ex 'run 60'

Вот полный пример.

$ 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

Поскольку /bin/sleep был (неудивительно), скомпилированный без отладки информации, вышеупомянутая обратная трассировка содержит минимальную информацию.

Вы не присоединяете , вы запустили . Это совсем другое, так как в этом случае gdb является прямым родителем debuggee и имеет полное право отлаживать его даже с помощью ptrace_scope==1. Это не сработает, если вы добавили , т. Е. Сделали что-то вроде sleep 60& gdb -ex "attach $!" — Ruslan, 5 January 2016 в 20:27
Предлагаемый (счетчик?) Пример Руслана sleep 60& gdb -ex "attach $!" не «использует gdb для запуска программы» и, следовательно, не является опровержением моего труда. Пример Руслана использует оболочку , чтобы сначала запустить sleep, а затем запустить gdb. Мое обходное решение работает , что меня волнует. Я не знаю и не забочусь о том, действительно ли gdb прикрепляется к своему ребенку. Я забочусь о возможности отладки ребенка. Мое обходное решение завершает это. Тем не менее, я изложил свой ответ для ясности. — mpb, 7 January 2016 в 01:46

mpb · Answer 15 · 2 August 2018 в 03:32

Если вы предпочитаете оставить /proc/sys/kernel/yama/ptrace_scope установленным по умолчанию значением 1, то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^C. Например, чтобы отлаживать (скучную) программу sleep 60, выполните следующие действия:

$ gdb -q sleep -ex 'run 60'

Вот полный пример.

$ 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

Поскольку /bin/sleep был (неудивительно), скомпилированный без отладки информации, вышеупомянутая обратная трассировка содержит минимальную информацию.

Вы не присоединяете , вы запустили . Это совсем другое, так как в этом случае gdb является прямым родителем debuggee и имеет полное право отлаживать его даже с помощью ptrace_scope==1. Это не сработает, если вы добавили , т. Е. Сделали что-то вроде sleep 60& gdb -ex "attach $!" — Ruslan, 5 January 2016 в 20:27
Предлагаемый (счетчик?) Пример Руслана sleep 60& gdb -ex "attach $!" не «использует gdb для запуска программы» и, следовательно, не является опровержением моего труда. Пример Руслана использует оболочку , чтобы сначала запустить sleep, а затем запустить gdb. Мое обходное решение работает , что меня волнует. Я не знаю и не забочусь о том, действительно ли gdb прикрепляется к своему ребенку. Я забочусь о возможности отладки ребенка. Мое обходное решение завершает это. Тем не менее, я изложил свой ответ для ясности. — mpb, 7 January 2016 в 01:46

mpb · Answer 16 · 4 August 2018 в 19:30

Если вы предпочитаете оставить /proc/sys/kernel/yama/ptrace_scope установленным по умолчанию значением 1, то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^C. Например, чтобы отлаживать (скучную) программу sleep 60, выполните следующие действия:

$ gdb -q sleep -ex 'run 60'

Вот полный пример.

$ 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

Поскольку /bin/sleep был (неудивительно), скомпилированный без отладки информации, вышеупомянутая обратная трассировка содержит минимальную информацию.

Вы не присоединяете , вы запустили . Это совсем другое, так как в этом случае gdb является прямым родителем debuggee и имеет полное право отлаживать его даже с помощью ptrace_scope==1. Это не сработает, если вы добавили , т. Е. Сделали что-то вроде sleep 60& gdb -ex "attach $!" — Ruslan, 5 January 2016 в 20:27
Предлагаемый (счетчик?) Пример Руслана sleep 60& gdb -ex "attach $!" не «использует gdb для запуска программы» и, следовательно, не является опровержением моего труда. Пример Руслана использует оболочку , чтобы сначала запустить sleep, а затем запустить gdb. Мое обходное решение работает , что меня волнует. Я не знаю и не забочусь о том, действительно ли gdb прикрепляется к своему ребенку. Я забочусь о возможности отладки ребенка. Мое обходное решение завершает это. Тем не менее, я изложил свой ответ для ясности. — mpb, 7 January 2016 в 01:46

mpb · Answer 17 · 6 August 2018 в 03:39

Если вы предпочитаете оставить / proc / sys / kernel / yama / ptrace_scope установленным по умолчанию значением 1 , то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^ C . Например, чтобы отладить (скучную) программу sleep 60 , выполните следующие действия:

  $ gdb -q sleep -ex 'run 60' [! D5]

  Вот полный пример. 
   $ gdb -q sleep -ex 'run 60' Чтение символов из сна ... (не найдены отладочные символы) ...  сделанный.  Начальная программа: / bin / sleep 60 ^ C Программный сигнал SIGINT, прерывание.  0x00007ffff7ad5d60 в __nanosleep_nocancel () на ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: Нет такого файла или каталога.  (gdb) backtrace # 0 0x00007ffff7ad5d60 в __nanosleep_nocancel () в ../sysdeps/unix/syscall-template.S:81 # 1 0x0000000000403cd7 in ??  () # 2 0x0000000000403b88 in ??  () # 3 0x00000000004016c9 in ??  () # 4 0x00007ffff7a35ec5 в __libc_start_main (main = 0x401540, argc = 2, argv = 0x7fffffffea08, init = & lt; optimized out & gt ;, fini = & lt; optimized out & gt ;, rtld_fini = & lt; optimized out & gt ;, stack_end = 0x7fffffffe9f8) в libc  -start.c: 287 # 5 0x00000000004017d5 in ??  () (gdb) continue Продолжение.  [Inferior 1 (процесс 3531) вышел из строя] (gdb) quit  
  Поскольку  / bin / sleep  был (неудивительно) скомпилирован без отладки информации, вышеупомянутая обратная трассировка содержит  минимальная информация.

mpb · Answer 18 · 7 August 2018 в 21:31

Если вы предпочитаете оставить / proc / sys / kernel / yama / ptrace_scope установленным по умолчанию значением 1 , то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^ C . Например, чтобы отладить (скучную) программу sleep 60 , выполните следующие действия:

  $ gdb -q sleep -ex 'run 60' [! D5]

  Вот полный пример. 
   $ gdb -q sleep -ex 'run 60' Чтение символов из сна ... (не найдены отладочные символы) ...  сделанный.  Начальная программа: / bin / sleep 60 ^ C Программный сигнал SIGINT, прерывание.  0x00007ffff7ad5d60 в __nanosleep_nocancel () на ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: Нет такого файла или каталога.  (gdb) backtrace # 0 0x00007ffff7ad5d60 в __nanosleep_nocancel () в ../sysdeps/unix/syscall-template.S:81 # 1 0x0000000000403cd7 in ??  () # 2 0x0000000000403b88 in ??  () # 3 0x00000000004016c9 in ??  () # 4 0x00007ffff7a35ec5 в __libc_start_main (main = 0x401540, argc = 2, argv = 0x7fffffffea08, init = & lt; optimized out & gt ;, fini = & lt; optimized out & gt ;, rtld_fini = & lt; optimized out & gt ;, stack_end = 0x7fffffffe9f8) в libc  -start.c: 287 # 5 0x00000000004017d5 in ??  () (gdb) continue Продолжение.  [Inferior 1 (процесс 3531) вышел из строя] (gdb) quit  
  Поскольку  / bin / sleep  был (неудивительно) скомпилирован без отладки информации, вышеупомянутая обратная трассировка содержит  минимальная информация.

mpb · Answer 19 · 10 August 2018 в 09:47

Если вы предпочитаете оставить / proc / sys / kernel / yama / ptrace_scope установленным по умолчанию значением 1 , то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^ C . Например, чтобы отладить (скучную) программу sleep 60 , выполните следующие действия:

  $ gdb -q sleep -ex 'run 60' [! D5]

  Вот полный пример. 
   $ gdb -q sleep -ex 'run 60' Чтение символов из сна ... (не найдены отладочные символы) ...  сделанный.  Начальная программа: / bin / sleep 60 ^ C Программный сигнал SIGINT, прерывание.  0x00007ffff7ad5d60 в __nanosleep_nocancel () на ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: Нет такого файла или каталога.  (gdb) backtrace # 0 0x00007ffff7ad5d60 в __nanosleep_nocancel () в ../sysdeps/unix/syscall-template.S:81 # 1 0x0000000000403cd7 in ??  () # 2 0x0000000000403b88 in ??  () # 3 0x00000000004016c9 in ??  () # 4 0x00007ffff7a35ec5 в __libc_start_main (main = 0x401540, argc = 2, argv = 0x7fffffffea08, init = & lt; optimized out & gt ;, fini = & lt; optimized out & gt ;, rtld_fini = & lt; optimized out & gt ;, stack_end = 0x7fffffffe9f8) в libc  -start.c: 287 # 5 0x00000000004017d5 in ??  () (gdb) continue Продолжение.  [Inferior 1 (процесс 3531) вышел из строя] (gdb) quit  
  Поскольку  / bin / sleep  был (неудивительно) скомпилирован без отладки информации, вышеупомянутая обратная трассировка содержит  минимальная информация.

mpb · Answer 20 · 13 August 2018 в 16:02

Если вы предпочитаете оставить / proc / sys / kernel / yama / ptrace_scope установленным по умолчанию значением 1 , то в качестве обходного пути вы можете рассмотреть возможность использования gdb для запуска программы, которую вы хотите отлаживать. Затем вы можете вызвать отладчик, просто нажав ^ C . Например, чтобы отладить (скучную) программу sleep 60 , выполните следующие действия:

  $ gdb -q sleep -ex 'run 60' [! D5]

  Вот полный пример. 
   $ gdb -q sleep -ex 'run 60' Чтение символов из сна ... (не найдены отладочные символы) ...  сделанный.  Начальная программа: / bin / sleep 60 ^ C Программный сигнал SIGINT, прерывание.  0x00007ffff7ad5d60 в __nanosleep_nocancel () на ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: Нет такого файла или каталога.  (gdb) backtrace # 0 0x00007ffff7ad5d60 в __nanosleep_nocancel () в ../sysdeps/unix/syscall-template.S:81 # 1 0x0000000000403cd7 in ??  () # 2 0x0000000000403b88 in ??  () # 3 0x00000000004016c9 in ??  () # 4 0x00007ffff7a35ec5 в __libc_start_main (main = 0x401540, argc = 2, argv = 0x7fffffffea08, init = & lt; optimized out & gt ;, fini = & lt; optimized out & gt ;, rtld_fini = & lt; optimized out & gt ;, stack_end = 0x7fffffffe9f8) в libc  -start.c: 287 # 5 0x00000000004017d5 in ??  () (gdb) continue Продолжение.  [Inferior 1 (процесс 3531) вышел из строя] (gdb) quit  
  Поскольку  / bin / sleep  был (неудивительно) скомпилирован без отладки информации, вышеупомянутая обратная трассировка содержит  минимальная информация.

Вы не attach , вы запустили . Это совсем другое, так как в этом случае gdb является прямым родителем debuggee и имеет полное право отлаживать его даже с помощью ptrace_scope == 1 . Это не сработает, если вы вместо прикреплены , то есть сделали что-то вроде sleep 60 & amp; gdb -ex "присоединить $!" — Ruslan, 5 January 2016 в 20:27

после обновления gdb не будет прикрепляться к процессу

20 ответов

Другие вопросы по тегам:

Похожие вопросы: