You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I try to run gdb -p manually, this is what happens:
(venv) homer tmp $ gdb -p 2503089
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
[...]
Attaching to process 2503089
ptrace: No such process.
(gdb)
So, I think that what happens under the hood is the following:
attach_debugger spawns gdb
the spawned gdb waits forever for user input (which will never happen)
the watchdog process waits forever for gdb to exit (which will never happen)
The solution is to enable ptrace globally. After running the following command, py -d works again:
(venv) homer tmp $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
I think that the proper behavior for attach_debugger should be to detect this case and warn the user. E.g.:
read the value of /proc/sys/kernel/yama/ptrace_scope and emit a clear error message, with links to the relevant documentation and maybe suggest to run the command above
try to detect whether the spawned gdb works correctly or not. This is harder because it would mean to modify _dbg.inject() to read and parse the output of the gdb commands
The text was updated successfully, but these errors were encountered:
This is problem which I ran into while trying to reproduce #131:
i.e., the
py
script just hangs indefinitely while trying to attach a debugger:_dbg.attach_debugger()
is implemented by spawning agdb -p <PID>
command, which tries to attach gdb to an existing processgdb -p
works by usingptrace
If I try to run
gdb -p
manually, this is what happens:So, I think that what happens under the hood is the following:
attach_debugger
spawnsgdb
The solution is to enable ptrace globally. After running the following command,
py -d
works again:I think that the proper behavior for
attach_debugger
should be to detect this case and warn the user. E.g.:/proc/sys/kernel/yama/ptrace_scope
and emit a clear error message, with links to the relevant documentation and maybe suggest to run the command above_dbg.inject()
to read and parse the output of the gdb commandsThe text was updated successfully, but these errors were encountered: