-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix gdb.attach
not working properly in x-terminal-emulator
#2363
Conversation
Hey, was the issue solved externally? |
nop... |
I'm afraid of race conditions when just adding one. Can we get the new pid more deterministically? We can at least check the proc.children() of the parent terminal somehow? |
Hello, I've made some modifications to the code. Now, it can address my issue without impacting #1922 |
Can you explain your reasoning behind this change please? |
Certainly, when debugging, I found that unlike tmux, gnome-terminal does not provide a method to directly retrieve the window pid (gdb_pid) such as through '-F' '#{pane_pid}', '-P'. When initialized using subprocess, gnome-terminal immediately pops up the window which has already been launched by the time wait_for_debugger is invoked. Consequently, at this juncture, the gdb_pid that we obtain through the p.pid method is actually the pid of the window, which is already operational. Henceforth, all we need to do is to ensure a successful trace to the process pid without disrupting the execution logic of tmux #1922 To achieve this, I switched 'break' to 'continue'. The system will subsequently keep invoking trace(pid) until it's not None, indicating that the process has been correctly traced. |
The idea of that loop was to stop waiting for the debugger to attach to the process when the debugger exits itself. So this patch isn't the way to go. I've recently faced a similar problem with launching gdb under WSL2 and fixed it in #2470 by waiting for the youngest new gdb process with a newer pid than the terminal we just started. It appears to be a good-enough and that logic could be reused here too? |
Hello sir, I installed the latest version of pwntools via pip in a new environment and retested. The issue is no longer present. However, I noticed that the pip-installed pwntools hasn't yet merged #2470 , so I'm unsure if it's related to my environment. Nonetheless, the issue is resolved. Thank you! |
You updated to 4.13.X? #2470 is only active when running in WSL2, so it shouldn't help in your case on Ubuntu. Do you still use gnome-terminal? It's weird that this fixed itself, but I'll take it. If you run into this problem again, please open a new issue 👍 |
fix: #2362